Jan Stary <h...@stare.cz> writes: >> >> >> 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.
>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="-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 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åns Rullgård _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
