Please help me understand & patch GCC re. "gcc -L/usr/lib -lz" problem, also "-nostdlib"

[Bob <obsdml@protonmail.com>]

Hi GCC users mailing list,

I am currently figuring out a GCC usecase on OpenBSD. This situation
involves some non-superficial understanding of GCC's code, and
therefore I wish to query you here even in the situation that it turns
out not to be needed.

I describe my problem here:
https://marc.info/?l=openbsd-misc&m=161472828522043&w=2

In summary my problem is that on OpenBSD, GCC will prepend to LD's
arguments "-L/usr/lib", which means that "-lz" NEVER will take my
local custom-built libz.so (which is what I want GCC/LD to do), but
instead always will take the OS-bundled libz.so which is in
/usr/lib/ , which is what I don't want.

In practice this means that I can't make a custom software build in
my home directory, that uses a custom libz (or any other .so whose
name also exists in /usr/lib), and I guess this also disturbs the
ability to do cross-platform builds. What I described now is a veru
normal usecase isn't it?


Here is to trig the behavior on OpenBSD:

$ echo "int main(){}">t.c; gcc -c -o t.o t.c; gcc -o t t.o -LMYDIRTEST -Wl,-v
collect2 version 4.2.1 20070719  (OpenBSD/x86-64 ELF)
/usr/bin/ld --eh-frame-hdr -e __start -Bdynamic -dynamic-linker /usr/libexec/ld.so \
-L/usr/lib -o t /usr/lib/crt0.o /usr/lib/crtbegin.o -LMYDIRTEST \
-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.7/4.2.1 t.o -v -lgcc -lc -lgcc \
/usr/lib/crtend.o LLD 8.0.1 (compatible with GNU linkers)

As you see here my "-LMYDIRTEST" comes after -L/usr/lib .

Normally on any Unix the -L/usr/lib is *appended to the end* of LD's
arguments, is it not - can you please confirm?

(This question affects why OpenBSD added a custom behavior.)


Second, a GCC patching question, your help to figure would be much
appreciated: OpenBSD's patchset to GCC v8 is in the patches
subdirectory here:

https://cvsweb.openbsd.org/ports/lang/gcc/8/

As I get it, GCC's default behavior is to put -L/usr/dir in the
trailing position, so one of these patches must modify GCC to put
it in the leading position instead. Can you tell me which line in which
patch file it is that has this effect?

(This way if I remove that line / file, GCC should behave the same as
on other platforms and my problem would be solved.)


Last for completeness a discussion of GCC's "-nostdlib" argument:

I figure that the since this very recent patch

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h.diff?r1=1.3&r2=1.4&f=h

, the GCC command line argument "-nostdlib" offers partial help, in
the form that adding it causes the *removal* of the leading
-L/usr/lib . However, there is no TRAILING -L/usr/lib so that one needs
to be added manually. And, especially, -nostdlib has a handful
other effects which I don't understand and which are not really
discussed anywhere, as I get it:

Grepping GCC's code for nostdlib gives me this:

gcc/cp/g++spec.c:	case OPT_nostdlib:
gcc/gcc.c:    %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} \
gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):" LIBASAN_EARLY_SPEC "} \
gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):" LIBASAN_SPEC "\
gcc/gcc.c:%{!nostdlib:%{fvtable-verify=std: -lvtv -u_vtable_map_vars_start -u_vtable_map_vars_end}\
gcc/gcc.c:    %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}} \
gcc/gcc.c:    %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
gcc/gcc.c:    %{!nostdlib:%{!nostartfiles:%E}} %{T*}  \n%(post_link) }}}}}}"

As you see the nostdlib logics are not in C/C++ code, but in some kind
of special GCC-internal language with its own syntax. Is this called
"GCC spec file" syntax?

The patch I referenced above, modifies
patches/patch-gcc_config_i386_openbsdelf_h 's line 11
from " +   -L/usr/lib\"" to "%{!nostdlib:-L/usr/lib}\"", again the
same syntax language.

Someone's discussion on what -nostdlib actually does, would be great
for the purpose of GCC documentation, the current description at
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html is too brief.


I'll wait for the OpenBSD mailing list to respond too. Any thoughts
much appreciated.

Bob