Re: Build system cleanup

["Måns Rullgård" <mans@mansr.com>]

Jan Stary <hans@stare.cz> writes:

> On Aug 22 11:10:10, mans@mansr.com wrote:
>> Jan Stary <hans@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.  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.  How you inform the linker
of their location isn't important, but it's your responsibility to do it
one way or another.  If one of the possible methods might in some odd
circumstance break something, that's also not a SoX problem.  Use
another one if that's the case.

-- 
Måns Rullgård


_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel