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

Wed Mar 3 18:43:10 GMT 2021

Hi Jonathan,

Thank you very much for your response.

Since the previous email I have had more correspondence with Marc at
the OpenBSD misc mailing list.

He clarified that the reason the -L/usr/lib prefix was added, was
"because of ld.ldd, the linker from clang. see, that one does not link
with /usr/lib by default, which tends to break everything.",

I asked him if it would not be better if GCC (both OS-bundled and port)
would locate the -L/usr/lib to the trailing position just like clang
does on OpenBSD and GCC does on all other platforms, and he responded:

> I have zero idea how to do that purely in specs. Have fun tinkering.
> This is probably something we'll adopt but low priority.


On my part, I have zero idea how to do this in GCC spec syntax too.

On Wednesday, 3 March 2021 14:16, Jonathan Wakely <> wrote:
> On Wed, 3 Mar 2021 at 12:35, Bob via Gcc wrote:
> > Here is to trig the behavior on OpenBSD:
> > 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:
> >
> > 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?
> It's done in several different files, one for each supported arch.
> You've already found where it's done for x86:
> The latest version has been fixed (as you say below) but the previous
> version added -L/usr/lib unconditionally. That LINK_SPEC is the first
> group of options passed to the linker. If -L/usr/lib is added to
> LINK_SPEC then it comes before any other -L options. In other words,
> there's no patch to say "put -L/usr/lib first instead of last"
> there's just a patch that puts it first.
> That's not how other targets do it, which is why -L/usr/lib doesn't
> come first for other targets, only for OpenBSD.

Can you please clarify what needs to be changed exactly on OpenBSD,
for the -L/usr/lib to come last instead of first?

Per what Marc said above here, your clarification should be
incorporated to become OpenBSD default configuration.

> > Last for completeness a discussion of GCC's "-nostdlib" argument:
> > -L/usr/lib . However, there is no TRAILING -L/usr/lib so that one needs
> > to be added manually.
> Of course. Because when you use -nostdlib ALL libraries and library
> paths need to be added manually. That's what it means.

For my situation, -nostdlib is overkill is it not?

> > And, especially, -nostdlib has a handful
> > other effects which I don't understand and which are not really
> > discussed anywhere, as I get it:
> They're discussed in the manual.

(Unimportantly but anyhow, I see no complete list of GCC arguments
that would need to be added, to reverse -nostdlib .)

> > Grepping GCC's code for nostdlib gives me this:
> > of special GCC-internal language with its own syntax. Is this called
> > "GCC spec file" syntax?
> Yes, documented at
> > 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.
> That means that -L/usr/lib is only added when -nostdlib is not used.


> > Someone's discussion on what -nostdlib actually does, would be great
> > for the purpose of GCC documentation, the current description at
> > is too brief.
> I don't see why it's too brief. It's quite accurate.
> The option means that GCC won't tell the linker to use any of the
> default libraries and library paths (which you can see by adding -v to
> the gcc command you use to link). That's accurate.

-nostdlib has no more effect than that? So it's about linking back
the C/C++ library and adding -L paths for GCC to find them. What about
crtbegin/end.o such?


More information about the Gcc mailing list