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 615E41F66E for ; Sun, 23 Aug 2020 14:07:57 +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 1k9qf0-00057z-Ow; Sun, 23 Aug 2020 14:07:50 +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 1k9qez-00057p-1Z for sox-devel@lists.sourceforge.net; Sun, 23 Aug 2020 14:07:49 +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=jpUNXv/+ViLWQkwhnGOYt6tA2BxvbKgR4AYExOTyE0w=; b=F0S3ODt59CdfztkpHO6CyJebvo pjdmdKZKFEp/dpi38b2ZYGXUXNfGQ15dc44RcfNiZloEojZI5Os25vIVvMLTu9gojz4zEhbCBcgvz MK58cLpwIpPSQHMLbpByhn63HZX6sjWY/aTxyKkgBJsucSpbj4ZarFu0nF1vH3L9LG/M=; 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=jpUNXv/+ViLWQkwhnGOYt6tA2BxvbKgR4AYExOTyE0w=; b=cvdgcboJkNM0RcBkSEHGGO9Pr1 S1QBS3UffnaU89BRs1fnsAMqwYtYElUQtu32ZvEqLASnWXn4o2/bi22BI02M2il2haFhjPxCg7giI tEzH3jer4T9xLxczc0BltaT9sJPHAXdpvdUmGqdusXNWayD8WfQssjJkvoklSzEWf+vg=; Received: from uvt.stare.cz ([185.63.96.79] helo=mx.stare.cz) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1k9qew-001mdd-2r for sox-devel@lists.sourceforge.net; Sun, 23 Aug 2020 14:07:49 +0000 Received: from localhost (stare.cz [local]) by stare.cz (OpenSMTPD) with ESMTPA id 3c8a8048; Sun, 23 Aug 2020 16:07:34 +0200 (CEST) Date: Sun, 23 Aug 2020 16:07:33 +0200 From: Jan Stary To: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= Message-ID: <20200823140733.GA9403@www.stare.cz> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1k9qew-001mdd-2r 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 > >> >> C_INCLUDE_PATH=/usr/local/include > >> >> LIBRARY_PATH=/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 libraries > > > > 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. > 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". > 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 > 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". > 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. Please stop pretending it's not a bug. Jan _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel