Debhelper: LDFLAGS
Daniel Stender
I am building with Debhelper 8 (dh $@) and I have a C source here which builds with several spurious
shlib dependencies detected by dpkg-shlibdeps. I've found that setting LDFLAGS to "--as-needed"
prevents overkill linking.
Where can I override the the auto build process? Just setting a custom LDFLAGS in debian/rules isn't
given through. Even an override_dh_auto_configure with "./configure LDFLAGS="-Wl,--as-needed" is
overwritten during build process.
Any pointers? Thanks in advance!
Greetings,
Daniel Stender
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D0E4900...@danielstender.com
Peter Pentchev
> Hi,
>
> I am building with Debhelper 8 (dh $@) and I have a C source here which builds with several spurious
> shlib dependencies detected by dpkg-shlibdeps. I've found that setting LDFLAGS to "--as-needed"
> prevents overkill linking.
>
> Where can I override the the auto build process? Just setting a custom LDFLAGS in debian/rules isn't
> given through. Even an override_dh_auto_configure with "./configure LDFLAGS="-Wl,--as-needed" is
> overwritten during build process.
>
> Any pointers? Thanks in advance!
When you say that setting the custom LDFLAGS doesn't work, have you
actually exported them? :) If you just do LDFLAGS=... or LDFLAGS != ...
or LDFLAGS := ..., make(1) will only use the new value *within the Makefile
itself*, it won't be passed to child processes such as the configure script.
Also, are you aware of the dpkg-buildflags utility available in recent
versions of dpkg-dev? :)
On both counts, feel free to take a look at recent versions of, say,
the timelimit (>= 1.6-1) package.
(shameless self-ad, of course, but IMHO it might be useful to you :)
G'luck,
Peter
--
Peter Pentchev ro...@space.bg ro...@ringlet.net ro...@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
What would this sentence be like if pi were 3?
Daniel Stender
dpkg-buildflags result here is empty) in debian/rules here doesn't work either.
Did I got it right: my builder debuild is a wrapper for dpkg-builpackage which calls dpkg-buildflags
to set the FLAGS (why between two dh_cleans?). The FLAGS then are efficient during the run of
./configure, isn't it?
Greetings,
Dan
On 19.12.2010 19:16, Peter Pentchev wrote:
> When you say that setting the custom LDFLAGS doesn't work, have you
> actually exported them? :) If you just do LDFLAGS=... or LDFLAGS != ...
> or LDFLAGS := ..., make(1) will only use the new value *within the Makefile
> itself*, it won't be passed to child processes such as the configure script.
>
> Also, are you aware of the dpkg-buildflags utility available in recent
> versions of dpkg-dev? :)
>
> G'luck,
> Peter
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D0E5382...@danielstender.com
Jakub Wilk
>When you say that setting the custom LDFLAGS doesn't work, have you
>actually exported them? :) If you just do LDFLAGS=... or LDFLAGS !=
>... or LDFLAGS := ..., make(1) will only use the new value *within the
>Makefile itself*, it won't be passed to child processes such as the
>configure script.
This is all true, but I don't think this is the culprit here.
dpkg-buildpackage puts LDFLAGS into environment, so it would be exported
even if you didn't use the "export" keyword.
If we are still talking about the gummi package, I just put
export LDFLAGS=-Wl,--as-needed
at top of debian/rules and the dpkg-shlibdeps warnings went away.
--
Jakub Wilk
Peter Pentchev
> * Peter Pentchev <ro...@ringlet.net>, 2010-12-19, 20:16:
> >When you say that setting the custom LDFLAGS doesn't work, have you
> >actually exported them? :) If you just do LDFLAGS=... or LDFLAGS
> >!= ... or LDFLAGS := ..., make(1) will only use the new value
> >*within the Makefile itself*, it won't be passed to child
> >processes such as the configure script.
>
> This is all true, but I don't think this is the culprit here.
> dpkg-buildpackage puts LDFLAGS into environment, so it would be
> exported even if you didn't use the "export" keyword.
Erm, yes, but dpkg-buildpackage doesn't see the LDFLAGS modified
in the rules file either, does it? If you put into the rules file
a line saying "LDFLAGS=-Wl,--as-needed" without the export keyword,
it would still not work - that was the point of my explanation,
just as you say below :)
> If we are still talking about the gummi package, I just put
>
> export LDFLAGS=-Wl,--as-needed
>
> at top of debian/rules and the dpkg-shlibdeps warnings went away.
G'luck,
Peter
--
Peter Pentchev ro...@space.bg ro...@ringlet.net ro...@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If I had finished this sentence,
Daniel Stender
>
> export LDFLAGS=-Wl,--as-needed
>
> at top of debian/rules and the dpkg-shlibdeps warnings went away.
Just like that? For some reason isn't working here ...
Daniel
--
http://www.danielstender.com/granthinam/
GPG key ID: 1654BD9C
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D0E66...@danielstender.com
Jakub Wilk
>>>When you say that setting the custom LDFLAGS doesn't work, have you
>>>actually exported them? :) If you just do LDFLAGS=... or LDFLAGS
>>>!= ... or LDFLAGS := ..., make(1) will only use the new value
>> >*within the Makefile itself*, it won't be passed to child
>>>processes such as the configure script.
>>
>>This is all true, but I don't think this is the culprit here.
>>dpkg-buildpackage puts LDFLAGS into environment, so it would be
>>exported even if you didn't use the "export" keyword.
>
>Erm, yes, but dpkg-buildpackage doesn't see the LDFLAGS modified
>in the rules file either, does it? If you put into the rules file
>a line saying "LDFLAGS=-Wl,--as-needed" without the export keyword,
>it would still not work - that was the point of my explanation,
>just as you say below :)
Nah, it would work just fine:
$ printf 'LDFLAGS=foo\nall:\n\t@echo LDFLAGS=\\"$$LDFLAGS\\"' > Makefile
$ unset LDFLAGS
$ make
LDFLAGS=""
$ export LDFLAGS=bar # set by evil dpkg-buildpackage
$ make
LDFLAGS="foo"
--
Jakub Wilk
Michael Biebl
> $ export LDFLAGS=bar # set by evil dpkg-buildpackage
Hm, seems I missed that part. Does dpkg-builpackage really set and *export* the
LDFLAGS env var?
That said, relying on dpkg-buildpackage to export the env variable means, you
get different builds if you run
fakeroot debian/rules binary
manually. I would be mighty confused by something like that. So I'd prefer
exporting the variable in debian/rules or using something like
LDFLAGS=-Wl,--as-needed
build:
./configure LDFLAGS=$(LDFLAGS)
make
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
>>>> When you say that setting the custom LDFLAGS doesn't work, have you
>>>> actually exported them? :) If you just do LDFLAGS=... or LDFLAGS
>>>> != ... or LDFLAGS := ..., make(1) will only use the new value
>>>> *within the Makefile itself*, it won't be passed to child
>>>> processes such as the configure script.
>>>
>>> This is all true, but I don't think this is the culprit here.
>>> dpkg-buildpackage puts LDFLAGS into environment, so it would be
>>> exported even if you didn't use the "export" keyword.
>>
>> Erm, yes, but dpkg-buildpackage doesn't see the LDFLAGS modified
>> in the rules file either, does it? If you put into the rules file
>> a line saying "LDFLAGS=-Wl,--as-needed" without the export keyword,
>> it would still not work - that was the point of my explanation,
>> just as you say below :)
>
> Nah, it would work just fine:
>
> $ printf 'LDFLAGS=foo\nall:\n\t@echo LDFLAGS=\\"$$LDFLAGS\\"' > Makefile
You missed the point here: the env vars are *not* passed to sub shells. As
configure is a shell script your example will not work. Try substituting echo
with a shell script and run the echo from within the shell script, if you want.
Jakub Wilk
>>>>>When you say that setting the custom LDFLAGS doesn't work, have you
>>>>>actually exported them? :) If you just do LDFLAGS=... or LDFLAGS
>>>>>!= ... or LDFLAGS := ..., make(1) will only use the new value
>>>>>*within the Makefile itself*, it won't be passed to child
>>>>>processes such as the configure script.
>>>>
>>>>This is all true, but I don't think this is the culprit here.
>>>>dpkg-buildpackage puts LDFLAGS into environment, so it would be
>>>>exported even if you didn't use the "export" keyword.
>>>
>>>Erm, yes, but dpkg-buildpackage doesn't see the LDFLAGS modified
>>>in the rules file either, does it? If you put into the rules file
>>>a line saying "LDFLAGS=-Wl,--as-needed" without the export keyword,
>>>it would still not work - that was the point of my explanation,
>>>just as you say below :)
>>
>>Nah, it would work just fine:
>>
>>$ printf 'LDFLAGS=foo\nall:\n\t@echo LDFLAGS=\\"$$LDFLAGS\\"' > Makefile
>
>You missed the point here: the env vars are *not* passed to sub shells.
>As configure is a shell script your example will not work. Try
>substituting echo with a shell script and run the echo from within the
>shell script, if you want.
This echo *is* a subshell. You'll get the very same results when you
substitute it with a shell script.
Here's the relevent piece of documentation:
http://www.gnu.org/software/autoconf/manual/make/Variables_002fRecursion.html
--
Jakub Wilk
Julien Valroff
Le dimanche 19 déc. 2010 à 21:09:34 (+0100), Daniel Stender a écrit :
> > If we are still talking about the gummi package, I just put
> >
> > export LDFLAGS=-Wl,--as-needed
> >
> > at top of debian/rules and the dpkg-shlibdeps warnings went away.
>
> Just like that? For some reason isn't working here ...
Dos your package use libtool?
If so, read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
Cheers,
Julien
--
,''`. Julien Valroff ~ <jul...@kirya.net> ~ <jul...@debian.org>
: :' : Debian Developer & Free software contributor
`. `' http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Stender
no it simply worked like Jakub said, the problem here was something completey different: I am
building with/within git-buildpackage and I just edited the wrong branch ... :-/
Greetings,
Daniel
On 20.12.2010 06:44, Julien Valroff wrote:
>> Just like that? For some reason isn't working here ...
>
> Dos your package use libtool?
>
> If so, read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
>
> Cheers,
> Julien
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D0F9582...@danielstender.com