> >> >> 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<include dir> if you have headers in a nonstandard directory <include dir> LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> 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