Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On Wednesday 25 of April 2012, David Ostrovsky wrote:
On 13.04.2012 11:35, Noel Grandin wrote:
On 2012-04-12 14:40, Stephan Bergmann wrote:
Insist on people compiling with an unbroken toolchain instead?

It looks like Fedora is also going to do this:
http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking

I'm willing to write a configure test to add the --no-as-needed flag
if someone can point me in the right direction.
I can follow the configure.in syntax easily enough, but what would be
the easiest way to test for the fact that the linker is defaulting to
--as-needed?

this is a tricky one, because ldd -r -u is not portalble.
We could create a lib, link it to binary but without actually using
something from that lib.

 That seems to be needlessly complex. If LO really can't build correctly 
with --as-needed and there are no intentions to fix that, it should be enough 
to just add --no-as-needed in the right place(s) to LDFLAGS, unconditionally 
(assuming the compiler/linker know this option, of course).

 That said, there are a number of distributions building that way (it's the 
default in openSUSE build service too AFAIK), so while 'everybody does that' 
is not an argument on its own, perhaps we should consider the possibility 
that it is not the toolchain that is broken.

-- 
 Lubos Lunak
 l.lunak@suse.cz

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.