disable as-needed by default?

[Michael Adam]

Björn Jacke wrote:
> On 2010-07-20 at 20:11 +0200 Volker Lendecke sent off:
> > My fear is the following: I have seen a failure on FreeBSD,
> > so I removed it. You were 100% certain to have fixed it and
> > thus re-added it. But in fact the FreeBSD linker failed in
> > a way that was unexpected. How many other unexpected failure
> > modes are still lurking out there?
> > 
> > The other fear is that even if the test is correct, we might
> > have configure tests before the as-needed tests that would
> > fail if run with as-needed but don't see that failure
> > because as-needed is only activated later. If this happened,
> > we would not see the failure before the final build. This
> > introduces a dependency on the order of configure tests that
> > every developer needs to be aware of.
> 
> the good thing about having features enabled by default is that we see when we
> break our own stuff. Distros use that flag nowadays most of the time if
> possible to minimize packet dependencies. Unfortunaely many packages have
> linker options wrongly ordered in their buildsystems, like we did, before we
> enabled it before 3.5. If we completely disable it now I bet it will take a
> couple of weeks until someome accidently adds linker options in the wrong order
> (object files after library flags) so that the feature will be broken again. 
> 
> So how about enabling it when --enable-developer is used and else leave it off
> by default? That way we will probably ensure we keep the build stuff clean and
> people out there who will not use --enable-developer will not run into whatever
> effects that might wait there.

Excellent idea. In fact I was about to suggest the same.
So we can monitor workings of as-needed without bothering
the end users.

+1 from me

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100721/64fcf0ce/attachment.pgp>