Your message dated Tue, 18 Oct 2016 10:54:12 +0000 (UTC)
with message-id <>
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

Debian Bug Tracking System
Contact 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 <>
* URL             :
* 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 

To access further information about this package, please visit the following 

Alternatively, one can download the package with dget using this command:

 dget -x

More information about hello can be obtained from

Changes since the last upload:

  cf-python (1.3.1-1) UNRELEASED; urgency=medium

  * Initial release (Closes: #777315)

 -- Klaus Zimmermann <>  Fri, 09 Sep 2016 17:31:55 +0200

 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.

well, using some "standard" naming from autoconf is better than using something 

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 

>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
>Via gcc:
>/usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin
>-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
>-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
>This includes link time optimization (lto) and adds standard runtimes
>(crt) and libraries (-lc, -lgcc).
>- 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 
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

$ gcc main.c -Wl,--as-needed -lz
$ gcc main.c -Wl,--no-as-needed -lz

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 :)


--- End Message ---

Reply via email to