Build Errors caused by LDFLAGS being added to other *FLAGS

[lucius-martius]

Currently, openssl fails for me with the following error:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognized option '-Wl'

(build.log)

Upon further inspection I can identify the issue:

x86_64-pc-linux-gnu-gcc -fPIC -pthread -m64 -Wa,--noexecstack -falign-functions=32 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=8 -fuse-linker-plugin -pipe -Wl,-Wl,--as-needed -Wl,-z,relro,-z,now -fno-strict-aliasing -Wa,--noexecstack -march=native -falign-functions=32 -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=8 -fuse-linker-plugin -pipe -Wl,-O1 -Wl,--as-needed -Wl,-z,relro,-z,now -fno-strict-aliasing -Wa,--noexecstack -L. -Wl,-znodelete -shared -Wl,-Bsymbolic -Wl,-O1 -Wl,--as-needed -Wl,-z,relro,-z,now -march=native -falign-functions=32 -O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=8 -fuse-linker-plugin -pipe -Wl,-soname=libcrypto.so.1.1

Notice the -Wl,-Wl,--as-needed. This seams due to the following line in the openssl ebuild:

        local DEFAULT_CFLAGS=$(grep ^CFLAGS= Makefile | LC_ALL=C sed \
                -e 's:^CFLAGS=::' \
                -e 's:-fomit-frame-pointer ::g' \
                -e 's:-O[0-9] ::g' \
                -e 's:-march=[-a-z0-9]* ::g' \
                -e 's:-mcpu=[-a-z0-9]* ::g' \
                -e 's:-m[a-z0-9]* ::g' \
                -e 's:\\:\\\\:g' \

Where -Wl,-O1 is replaced by -Wl,.

This got me thinking. Why are LDFLAGS added to CFLAGS etc.? I've noticed it before, but never given it much thought.

Turns out, it's a quirk in portage-bashrc-mv.

And in fact, if I add NOLDADD=1 to my make.conf, OpenSSL builds fine.

Should NOLDADD=1 be added to make.conf.lto to avoid problems like this or is there any benefit to having all these -Wl flags in CFLAGS?

[lucius-martius]

On second thought. This issue has nothing to do with GentooLTO, but solely with the use of portage-bashrc-mv.

But maybe a hint could be added to make.conf.lto to have the user add NOLDADD=1 to his make.conf if (rather when) he encounters build errors.

Or should this rather be closed because it is not the fault of GentooLTO?

[thrifty-txt]

Thanks for posting this, I've been having the exact same issue with openssl for days with/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognized option '-Wl' and your fix worked!
I have been too scared to open an issue as I thought I fucked something up ^_^

[javashin]

yeSSS

[javashin]

its bashrc fault i been moving the mv and lto files from /etc/protage to build some pkgs never known about NOLOADDD-=1

[lucius-martius]

I don't think it's necessarily "portage-bashrc-mv's fault" either. After all, -Wl,-O1 is a valid flag to GCC, it's just ignored if linking happens in a different step (which is usually the case). And vaeth gives a good explanation on possible usage scenarios of this behavior and provides an option to turn it off in the issue I've linked to above. I'd argue the defaults should be reversed, since it's a rarely necessary optimization you could enable on on a per-package basis, but that's just my opinion.

I'm also not an experienced ebuild developer/maintainer, but I'm not sure compiler flags should be parsed with such simple regex commands as they are in dev-libs/openssl. It seems to me like you could never possibly account for all possible compiler flags like this in a maintainable way, like this bug shows. So if it is anyone's "fault", it would be the ebuild.

[jiblime]

This is interesting. So how would one diagnose if LDFLAGS were not respected in an ebuild? I know that LDFLAGS are specifically meant for linking libraries so I was confused as to why I was getting libraries appended to my CFLAGS. And I am curious which builds were having this issue, too.

Edit: I can also confirm that appending NOLDADD=1 fixes an OpenSSL emerge.

[ElDavoo]

Same problem here, same fix worked

[corrmaan]

https://bugs.gentoo.org/671016

[sandikata]

Too many troubles with -Wl, as it's unrecognised option..