On Wednesday, 3 March 2021 16:21, Marc Espie <[email protected]> wrote:
> Do you have some actual reason to use gcc for that project instead of
> clang ?...
...
> But again: why gcc ?
Hi Marc,
Thank you very much for responding.
I am in a special code project that is centered around unique GCC
features and I can absolutely not move to clang now without enduring
great pains. I hope that clang will have some tweaks so that I can
move to it, however expectably it will take clang 2-3 years to do that.
Indeed my situation is slightly uncommon.
> it's been a long time since I've last looked at gcc, we've moved to clang
> a few years ago for the most part. gcc is mostly there for the legacy
> architectures that do not have clang support.
>
> Oh, I remember now, it's because of ld.ldd, the linker from clang.
> see, that one does not link with /usr/lib by default, which tends to break
> everything.
Thank you very much for clarifying why OpenBSD GCC adds a -L/usr/lib
to LD that GCC on other platforms does not have.
Here an immediate followup question:
Does that -L/usr/lib really need to be in the leading position???
I'm asking myself if adding it in the leading position was even
deliberate. Also was it maybe just a convenient choice due to some
technicality of spec file syntax, such.
What I see clang do both on OpenBSD and other platforms, and GCC do on
other platforms, is that they do add -L/usr/lib to LD, but they do it
in the trailing position.
Would doing so be fine for the purpose you just described, also?
If it would be fine, what about actually moving OpenBSD's GCC (bundled
& port) to do that?
For completeness, here example output of clang on OpenBSD:
$ echo "int main(){}">t.c; clang -c -o t.o t.c ; clang -o t t.o -LMYDIRTEST
-Wl,-v --verbose
OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1)
Target: amd64-unknown-openbsd6.7
Thread model: posix
InstalledDir: /usr/bin
"/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker
/usr/libexec/ld.so -o t /usr/bin/../lib/crt0.o /usr/bin/../lib/crtbegin.o
-LMYDIRTEST -L/usr/bin/../lib -L/usr/lib t.o -v -lcompiler_rt -lc -lcompiler_rt
/usr/bin/../lib/crtend.o
LLD 8.0.1 (compatible with GNU linkers)
As you see, clang adds -L/usr/lib too (in the form
"-L/usr/bin/../lib"), however does so in trailing position.
Here is what GCC on Debian does:
$ gcc -v
[..]
gcc version 8.3.0 (Debian 8.3.0-6)
$ echo "int main(){}">t.c; gcc -c -o t.o t.c ; gcc -o t t.o -LMYDIRTEST -Wl,-v
collect2 version 8.3.0
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccd7waom.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -o t
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o -LMYDIRTEST
-L/usr/lib/gcc/x86_64-linux-gnu/8
-L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. t.o -v -lgcc --push-state
--as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s
--pop-state /usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils for Debian) 2.31.1
As you see it does just the same as clang: it adds -L/usr/lib , however
in trailing position.
> Note that you don't have to recompile gcc to change that: the specs file
> is where the magic happens, and hey, you can specify a new one on the command
> line, so you just need to copy and change.
Brilliant, also thanks for pointing out. To navigate this question,
* Where is GCC's default specs file say for AMD64/i386?
* Using what environment variable or GCC command line argument do
I specify an alternative one?
> as far as -L goes you've got a lot of choices, between linking directly to
> the .so, linking with --nostdlib and putting back the pieces manually.
I agree there are alternatives however they come with great pains:
* Switching GCC/LD argument from "-lz" to "libz.so" indeed works,
however it's very difficult to do this in other people's code,
projects generally are hardwired to the "-lz" form, e.g. Boost.
* -nostdlib does many things and skipping the -L/usr/lib is only one
of them. It appears an unnecessarily strong measure for what I want
to achieve. If I used it, I'd need to figure out a set of
additional arguments to counter all effects -nostdlib has, that I
don't want.
Thus in summary altering my local GCC spec file (or if this feedback
makes all sense, OpenBSD's default behavior changing) appears
preferable.
Looking forward to learn your take.
Bob
