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=-4.3 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 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 A58091F66E for ; Sun, 23 Aug 2020 17:14:04 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1k9tZ8-0004wx-4d; Sun, 23 Aug 2020 17:13:58 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k9tZ7-0004wq-59 for sox-devel@lists.sourceforge.net; Sun, 23 Aug 2020 17:13:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version :Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: 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=7EG4KmQ03dXwuS9jaL9Hdb6q4J7RL+PU5WmWEYBuUCc=; b=YAqn9WbQvFruYRxn9otQyHlZpG R1gQH8FiYIFY9b2c0GOp1fJnQeS3+1Ci4bV2uPIEmQB4MGCjPoutO2ezBbDgPk2VRgmMNBkepebYf Mi1goilNd6FBlHzZKxV6Y8wM/BViRi0Oaz/xmIiDh7HG1xyGZ3ew3hYAJUuALJxUWcXE=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: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=7EG4KmQ03dXwuS9jaL9Hdb6q4J7RL+PU5WmWEYBuUCc=; b=IlAW9Ouu1UdWv6sS7xz+6K2pmy L16DrdBCG3dJAgNHnC9AnQA7ZG95wZuVH8jw4qAoOz8Xq7up7CVnXu/QeLekXpJOo0C3QuiwK1LTN d4uqtLMjEfDCS79BTYb3ijJ5IqWB7QdTfIFBEN+Kix1Fulb/S0NZxU8FjAuaMr/vY3NM=; Received: from unicorn.mansr.com ([81.2.72.234]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1k9tZ5-00GKk5-D3 for sox-devel@lists.sourceforge.net; Sun, 23 Aug 2020 17:13:57 +0000 Received: from raven.mansr.com (raven.mansr.com [81.2.72.235]) by unicorn.mansr.com (Postfix) with ESMTPS id 99EF015360; Sun, 23 Aug 2020 18:13:43 +0100 (BST) Received: by raven.mansr.com (Postfix, from userid 51770) id 3F33A21A6F2; Sun, 23 Aug 2020 18:13:43 +0100 (BST) From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Jan Stary References: <20200821174358.GA88757@www.stare.cz> <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> Date: Sun, 23 Aug 2020 18:13:43 +0100 In-Reply-To: <20200823140733.GA9403@www.stare.cz> (Jan Stary's message of "Sun, 23 Aug 2020 16:07:33 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Headers-End: 1k9tZ5-00GKk5-D3 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: sox-devel-bounces@lists.sourceforge.net Jan Stary writes: >> >> >> C_INCLUDE_PATH=3D/usr/local/include >> >> >> LIBRARY_PATH=3D/usr/local/lib >> >> > >> >> > I never used any of these. >> >> > Are they docummented anywhere? >> >> = >> >> Many compilers/linkers support such environment variables. The gcc >> >> manual documents them here: >> >> https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html >> > >> > I am not using the gcc compiler. >> > The default OpenBSD/amd64 compiler is clang. >> = >> The same settings are used by clang. >> = >> >> These are the preferred method for indicating the location of librari= es >> > >> > Where does this information come from? >> > ./configure says something else. >> > >> > If the above is endeed preferrable (which I doubt), >> > we have to fix configure to stop recommending >> > something else than the recommended way. >> > >> >> since they augment the compiler's default search path without >> >> interfering with command-line options which are searched first. >> > >> > In the same way, ./configure *FLAGS augment the compiler's path(s) >> > without "interfering" with the environment >> > - how is one preferable to the other? >> = >> 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. >> 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. >> 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=3D"-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. >> 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? > > 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. >> 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, and there is no reason why there would be. The link command in the makefile hasn't changed. > Please stop pretending it's not a bug. It builds without problems on a clean OpenBSD install. 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. I have no idea what you've done to your system, but you're barking up the wrong tree. I'm done wasting time on this. -- = M=E5ns Rullg=E5rd _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel