On Wed, Oct 09 2019, Christopher Zimmermann <chr...@openbsd.org> wrote:
> On Tue, Oct 08, 2019 at 01:44:14PM +0200, Jeremie Courreges-Anglas wrote:
>> On Tue, Oct 08 2019, Christopher Zimmermann <madro...@gmerlin.de> wrote:
>> > On Mon, Oct 07, 2019 at 09:09:50PM +0100, Stuart Henderson wrote:
>> >> On 2019/10/07 21:37, Christopher Zimmermann wrote:
>> >> > How is an arbitrary piece of software supposed to
>> >> > discover /usr/local/include and /usr/local/lib?
>> >>
>> >> The same way it will discover /opt/include and /opt/lib on a linux box -
>> >> you tell it to look there.
>> >
>> > - What's the preferred way to teach a build system our search paths ?
>> > - What's the preferred / most portable way for a piece of software to
>> > discover the search paths?
>> >
>> > Is it pkg-config, $CPATH / $LIBRARY_PATH, autoconf, something else?
>>
>> Many build systems have support for pkg-config (eg pkg.m4 for autoconf).
>> autoconf honours (at least) CPPFLAGS/CFLAGS/LDFLAGS.
>> CPATH and LIBRARY_PATH are OCaml idioms AFAIK.
>
> Quite contrary CPATH and LIBRARY_PATH are variables heeded by gcc and
> clang compiler and linker.
Hah, indeed, I had completely forgotten about this.
> I did some experiments:
>
> $ echo '#include<bzlib.h>' >incl_test.c
> $ CPATH= cc -E -Wp,-v incl_test.c >/dev/null
> clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
> amd64-unknown-openbsd6.6
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/clang/8.0.1/include
> /usr/include
> End of search list.
> incl_test.c:1:9: fatal error: 'bzlib.h' file not found
> #include<bzlib.h>
> ^~~~~~~~~
> 1 error generated.
> $ CPATH=/usr/local/include cc -E -Wp,-v incl_test.c >/dev/null
> clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
> amd64-unknown-openbsd6.6
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/include
> /usr/lib/clang/8.0.1/include
> /usr/include
>
> But this is _really_ unexpected:
>
> $ CPATH= echo '#include<bzlib.h>' |cc -E -Wp,-v - >/dev/null
> clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
> amd64-unknown-openbsd6.6
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/include
> /usr/X11R6/include
> /usr/lib/clang/8.0.1/include
> /usr/include
> End of search list.nd of search list
>
> This tells me that the preprocessor has a decent idea of our search
> path, but forgets about /usr/local and /usr/X11R6 includes when a file
> is passed as argument instead of run in a pipe.
>
> The heck why does it do that?
Your command doesn't do what you think it does.
> CPATH= echo '#include<bzlib.h>' |cc -E -Wp,-v - >/dev/null
CPATH is only clobbered for the first command in the pipe, 'echo'. 'cc'
still inherits whatever is in CPATH, and I guess it's set to a custom
value. Did you actually remove CPATH/LIBRARY_PATH from your
/etc/profile? ;)
--8<--
russell ~/tests$ echo '#include<bzlib.h>' | CPATH= cc -E -Wp,-v - >/dev/null
clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target
amd64-unknown-openbsd6.6
ignoring nonexistent directory "/usr/lib/clang/8.0.1/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
End of search list.
<stdin>:1:9: fatal error: 'bzlib.h' file not found
#include<bzlib.h>
^~~~~~~~~
1 error generated.
-->8--
>> There's no single answer.
>
> Of course not.
>
>> Can opam simply inject -I/usr/local/include and -L/usr/local/lib in the
>> dune build system used by ocaml-lmdb?
>
> Since the C compiler/linkers heed CPATH and LIBRARY_PATH, I can simply
> set those variables to inject the standard search path.
> But why do I even have to do that? The preprocessor seems to know the
> correct search path, but seems to forget it under some circumstances.
By design our base compilers aren't supposed to look into /usr/local or
/usr/X11R6.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
