From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS, UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 540B21F66E for ; Sun, 23 Aug 2020 19:47:17 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1k9vxM-0007I9-L8; Sun, 23 Aug 2020 19:47:08 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9vxL-0007I2-QC for sox-devel@lists.sourceforge.net; Sun, 23 Aug 2020 19:47:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0dYgeJxfVMEWgDzcWNSxnwfHdZQaMad2148il6sw5W4=; b=TJmH3cJb30NiNDCYpmUBioL4r7 Hk6r/Aanbltl5aPCxaPIBuMYb9JthZAMEUh0U1UmPAP9SwB6CWjRLJAPoiRaVVUrCOqVqafZnTjTK xDyHI5h55eLRqEzZ9ZUf+Im05WknIax3nA+iy7ntuW6EF8aVJyDaPapuBDTI1w28fc2I=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0dYgeJxfVMEWgDzcWNSxnwfHdZQaMad2148il6sw5W4=; b=JqBBmLIun7LHp0LCrrgqyCGzos 3GTjriOSY/7bw9yeTFlvs7XtnPUN1dxV+2wDdqVKV5bxZClNM75x2ByaQrRNekhQ2LfSqmepl2HH4 DFyZ8/cVI1Li7dMTo6Drizfx8G93lrPq2bYuEyWT6Zkc0BClbHTTcyL330Z/QjvaBYFc=; Received: from uvt.stare.cz ([185.63.96.79] helo=mx.stare.cz) by sfi-mx-4.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1k9vxJ-004lhC-1u for sox-devel@lists.sourceforge.net; Sun, 23 Aug 2020 19:47:07 +0000 Received: from localhost (stare.cz [local]) by stare.cz (OpenSMTPD) with ESMTPA id 9c0cc5dd; Sun, 23 Aug 2020 21:46:49 +0200 (CEST) Date: Sun, 23 Aug 2020 21:46:49 +0200 From: Jan Stary To: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= Message-ID: <20200823194649.GA68664@www.stare.cz> References: <20200821201758.GA23884@www.stare.cz> <20200821204550.GA67586@www.stare.cz> <20200822081738.GA14321@www.stare.cz> <20200822153545.GA61858@www.stare.cz> <20200823140733.GA9403@www.stare.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1k9vxJ-004lhC-1u Subject: Re: Build system cleanup X-BeenThere: sox-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sox-devel@lists.sourceforge.net Cc: sox-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: sox-devel-bounces@lists.sourceforge.net > >> It's simple. The linker looks for libraries in > >> > >> 1. -L flags, in order > >> 2. The LIBRARY_PATH environment variable > >> 3. Compiled-in defaults, typically /usr/lib and /lib > >> > >> It is the responsibility of the system administrator to configure things > >> in such a way that system libraries are found by the system linker. > > > > These are not system libraries. > > These are add-on third party packages such as flac etc. > > >From the point of view of SoX, there is no difference. They are > libraries supplied by the system administrator, and it is your job as > such to tell the compiler where to find them. The libraries might just as well be installed in the $HOME of any user trying to build SoX for himself, so the admin has nothing to do with it either. But of course the build system needs to be told where the libs are. > >> On normal systems, this is achieved by installing add-on libraries > >> somewhere the linker looks by default, such as /usr/lib, > >> or occasionally by setting the relevant variables > >> in the default environment. If OpenBSD chooses to install > >> packages outside the normal search path of > >> the linker, that's really not a SoX problem. > > > > Do I sense the GNU "portability" attitude here? > > > > Everything as GNU/Linux does -> we work > > Anything else -> fuck them > > > It is perfectly OK for a system to install third-party software > > wherever they like, be it /usr/local on OpenBSD (and other *BSDs), > > /opt/local with MacPorts, or /opt/sfw with Solaris. > > > > It is the build system's job, by definition, to accomodate > > these variations, such as header and library paths. > > Which is exactly what the ./configure script is for. > > > > You know that, don't you? But here you go implying that systems > > that install anywhere else but /usr are not "normal". > > SoX builds perfectly fine on OpenBSD once you set two environment > variables. It's not my problem that OpenBSD is designed so as to > require this. By the two variables, you mean C_INCLUDE_PATH and LIBRARY_PATH I presume. It used to work by setting CPPFLAGS and LDFLAGS (two other variables, which, unlike the former two, are explicitly documented in the INSTALL file, the README.* files, and the output of ./configure), for a long time -- and now it doesn't. That's called a regression. I am reporting this regression because you asked for problems when building on *BSD specificaly. The "design of OpenBSD" has nothing to do with it; I can only assume you know that. > >> How you inform the linker of their location isn't important, > >> but it's your responsibility to do it one way or another. > > > > The way I inform the linker is the way INSTALL and ./configure tells me > > to go, namely, to pass CFLAGS and CPPFLAGS and LDFLASG. That is what: > > > > 1. the INSTALL file explicitly tells the builder to do > > > > Selection of optional libraries and of other build options > > can be made by adding parameters to the `./configure' command line > > Run ./configure --help for a complete list of options. > > [...] > > If any libraries are installed in a non-standard locations in your > > system then you can use the CPPFLAGS and LDFLAGS variables to allow > > configure to find them. For example: > > > > ./configure CPPFLAGS="-I/usr/local/multimedia/include" [...] > > > > 2. ./configure --help describes > > > > CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if > > you have headers in a nonstandard directory > > > > LDFLAGS linker flags, e.g. -L if you have libraries in a > > nonstandard directory > > > > 3. has worked for decades > > 4. does not work in the new-build branch > > Nothing has changed in how CFLAGS or LDFLAGS are used. Yet what used to work no longer works in the new-build branch; god knows what else has changes in the smelly guts of autotools -- the M4 macros have changed for one thing (not saying that's it). But placing the -L/usr/local/lib in a different place with ./configure ./configure LDFLAGS=-L... respectively, so that the linking command fails with the latter, is a bug at any rate. Do you agree it is a bug? > >> If one of the possible methods might in some odd > >> circumstance break something, that's also not a SoX problem. > > > > Doing exactly what INSTALL and ./configure say results in > > a failed build, and you don't consider it a problem? Do you? > > Repeat after me: having extra headers and libraries > > in /usr/local is not "some odd circumstance". > > No, and it works just fine if you supply the correct build environment. What "correct build environment"? The one described in INSTALL and all the build examples for various other systems (osx, ...)? No, it desn't. > >> The result is in the 'new-build' git branch. > >> I'd appreciate if people, especially on BSD, > >> could give it a try and report any problems. > > > > Well here it is. > > > > And we already know what the problem is: > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...] > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...] > > > > The first works, the second does not. > > The only difference between the two is the place > > where the extra -L/usr/local/lib gets added, > > as described in the previous emails. > > There is no such difference on my OpenBSD system, Can you please post the two script(s) for ./configure CC=cc ./configure CC=cc CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib respectively, and the subsequents make's? Then I'll believe there is no difference on your system. (You have tried them both, right?) The difference is not caused by some property or design of OpenBSD. It is caused by running SoX's ./configure with or, respectively, without the documented LDFLAGS argument. That's a bug. Do you agree that it's a bug? > and there is no reason why there would be. "Would be"? There is. Look. > > Please stop pretending it's not a bug. > > It builds without problems on a clean OpenBSD install. Apparently, it doesn't. > If you've screwed up your system somehow, that's your problem. > It is unreasonable of you to demand that the SoX build system > anticipate and accommodate every possible misconfiguration. Here we go. There's a regression in the new-build. You get a report that what used to work on OpenBSD now doesn't. The result: that system is "screwed up" (wait: I have screwed it up); it's a "misconfiguration". We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH into ./configure's environment produces a working link command; passing CPPFLAGS and LDFLAGS to ./configure also used to produce a working command, but now produces a failing link line; the position of -L seems to be the difference. Question: How is that related to the OS? Answer: The libs are not in /usr (where the GNU tools expect everything to be), so you have to pass that information somehow. The problem seems to be in passing that information. Question: But how is that related to _the_actual_OS_? Answer: It isnt't; eventually, it's a "cc -I... -L..." line produced by the autotools that govern the build of SoX. > I have no idea what you've done to your system Guess what: it hasn't changed since before you posted the new-build branch. > but you're barking up the wrong tree. Apparently - I thought I was talking to the maintainer. > The result is in the 'new-build' git branch. > I'd appreciate if people, especially on BSD, > could give it a try and report any problems. Yeah, right. _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel