Your message dated Tue, 18 Oct 2016 10:54:12 +0000 (UTC)
with message-id <1946329441.4594870.1476788052...@mail.yahoo.com>
and subject line Re: Bug#837650: RFS: cf-python/1.3.1+dfsg.1-1 [ITP]
has caused the Debian Bug report #837650,
regarding RFS: cf-python/1.3.2+dfsg1-1 [ITP]
to be marked as done.
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
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
Dear mentors,
I am looking for a sponsor for my package "cf-python"
* Package name : cf-python
Version : 1.3.1-1
Upstream Author : David Hassell <david.hass...@ncas.ac.uk>
* URL : http://cfpython.bitbucket.org/
* License : Expat
Section : python
It builds those binary packages:
python-cf - Python processing of Climate and Forecast (CF) data models
(Python 2)
python-cf-doc - Python processing of Climate and Forecast (CF) data models
(Documentation)
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/cf-python
Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/c/cf-python/cf-python_1.3.1-1.dsc
More information about hello can be obtained from https://www.example.com.
Changes since the last upload:
cf-python (1.3.1-1) UNRELEASED; urgency=medium
* Initial release (Closes: #777315)
-- Klaus Zimmermann <klaus_zimmerm...@gmx.de> Fri, 09 Sep 2016 17:31:55 +0200
Regards,
Klaus Zimmermann
--- End Message ---
--- Begin Message ---
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.html
http://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.
--- End Message ---
