Advertising

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
837650: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837650
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Hi, sorry for the delay!
>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.
https://lists.gnu.org/archive/html/autoconf/2004-01/msg00181.htmlhttp://stackoverflow.com/questions/519342/what-is-the-difference-between-i-and-l-in-makefile
well, using some "standard" naming from autoconf is better than using something
different
and new, but I agree, I have been always using autoconf naming.
(and I see on the web/Debian world, this convention seems to be a de-facto
standard)
>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 is my point:
$ cat main.c
#include<zlib.h>
#include<stdio.h>
int main()
{
printf("%s", zlibVersion());
return 0;
}
$ gcc -Wl,--as-needed -lz main.c
/tmp/ccV8in0B.o: In function `main':
main.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status
$ gcc -Wl,--no-as-needed -lz main.c
works
$ gcc main.c -Wl,--as-needed -lz
works
$ gcc main.c -Wl,--no-as-needed -lz
works.
So, having the library at the end works *always* having at the begin works
only when as-needed is not a CFLAG or is not the default.
Your package will probably work in Debian, but not in Ubuntu, because the flag
will be
dropped and not considered for the linker.
Right now this isn't an issue, because there aren't libraries linked with it,
but I still
prefer having them at the bottom, to avoid future issues.
Hope you got the point :)
Now, I see you have a difference between LDFLAGS and LIBS, and if you put
libraries in the correct
variable, you won't be bitten by this issue :)
(the main point is that usually upstream has a single LDFLAGS contains
everything, so at the end
of the line is the safer option)
Anyway, built, signed, uploaded, and git tagged :)
G.