Bug#837650: RFS: cf-python/1.3.1+dfsg.1-1 [ITP]
Hi Gianfranco,
Am 11.10.2016 um 08:25 schrieb Gianfranco Costamagna:
>>> $(LDFLAGS)<-- this should be at the end of the line, not at the begin, otherwise
>>> you might see some libraries stripped just because the .o files needing them
>>> are put after (this happens when wl-asneeded is used/default)
>
>> Hm, GNU make disagrees with you here. The built-in rule for linking is
>> $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $@
>
> GNU make file seems to be wrong here then :)
> how can you use LDFLAGS with CC?
> you can use them only with $(LD) invocation.
Let me start by saying that I don't have strong opinions here, I am just
trying to figure it out.
However, in general it seems to be highly encouraged to not call ld
directly, but instead to call gcc, even for linking.
This acts as the general interface to all stages, including the linking,
in this case calling ld in turn.
I guess that this is one reason why they changed the meaning from gnu c
compiler to gnu compiler collection at some point.
For a reference see this stackoverflow answer
http://stackoverflow.com/a/8694291
I agree, that a stackoverflow answer is not exactly the best kind of
reference, but also note the comment by the venerable Lars Wirzenius.
Together with the make built-in rule this makes a consistent case, in my
view, that linking should be done via gcc, not ld directly.
So let's pick the rule a bit apart:
> Do you have any documentation here? I admit this seems wrong in many places, e.g.
> LOADLIBES is something deprecated long time ago
True. This is also stated in the documentation [1] under LDLIBS, and is
included in the built-in rule just for compatibility reasons.
> LDLIBS is now mostly unused, and LIBS is used instead.
Do you have a reference for this? I found no mention of LIBS in the make
manual or the implicit rules. Those consistently use LDLIBS instead.
It seems that autoconf uses LIBS, but this is not our case.
> LDFLAGS is moved at the bottom, but only when LD is invoked.
I was curious to see how gcc would invoke ld, so I modified the Makefile
to invoke ld directly and then via gcc, noting the actual call with the
help of the -v option.
Naked ld:
ld -shared \
umfile.o error.o filetype.o malloc.o linklist.o new_structs.o
swap.o --whole-archive type-dep/umfile_typedep.a --no-whole-archive \
-o umfile.so
Via gcc:
/usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccNXvmVo.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 --sysroot=/ --build-id --eh-frame-hdr
-m elf_x86_64 --hash-style=gnu --as-needed -shared -z relro -o umfile.so
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o
-L/usr/lib/gcc/x86_64-linux-gnu/5
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../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/5/../../.. umfile.o
error.o filetype.o malloc.o linklist.o new_structs.o swap.o
--whole-archive type-dep/umfile_typedep.a --no-whole-archive -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-linux-gnu/5/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o
This includes link time optimization (lto) and adds standard runtimes
(crt) and libraries (-lc, -lgcc).
Conclusion:
-----------
- Linking should be done via gcc, not ld directly.
- I updated the rule again to a stripped down version of the built-in
rule that seems appropriate to me.
I hope you agree.
> This seems to be the last showstopper, the other stuff looks good to me now :)
Great!
> (and it might be that you are right and I'm wrong, in that case I'll sign and upload as-is, just
> please enlighten me about this!)
>
> thanks,
>
> G.
>
Thanks again for all the help and time!
Cheers
Klaus
[1]
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
Reply to: