Re: Build Error

On 24.10.2012 17:19, Stephan Bergmann wrote:
> On 10/24/2012 04:57 PM, Joel Madero wrote:
> > On 10/24/2012 07:28 AM, Joel Madero wrote:
> > > Not that I know of. I haven't changed my method at all. I've been 
> > > basing my make
> > > of the same ./autogen that I've been using for months.
> > >
> > > Do I have to change something? If so, suggestions on how to do it? 
> > > Appreciate
> > > it, this is becoming an issue as I can't triage correctly without a 
> > > master build
> >
> > To track down what's really going on there, can you execute the three
> > following lines each from a shell where you would issue the failing
> > "make" and capture the output please:
> >
> > > echo $LD_LIBRARY_PATH
> >
> > /usr/lib
>
> So that's the bug.  Having LD_LIBRARY_PATH set globally (esp. to a 
> directory ld-linux.so would consult anyway) is rather silly.
I agree with you that such system wide setting is really odd. I was 
curious why bodhi guys did it and asked on #bodhilinux on freenode.
The answer is: the didn't. They inherited that setting from LXDM 
configs. To find out why one should probably take a Look
at the LXDM patches on packages.ubuntu.com.

But basically this discussion remind me debian/ubuntu linker 
configuration change, defaulting to : --as-needed per default.

Given that we should make the life of our contributors as easy as 
possible we can ask if that recently introduced feature:
(7a8e82a4e3806d5bd500eb6e553e0f40e4d33419)
"Honour preset LD_LIBRARY_PATH etc" per default (!) in LO compile 
process adhere to these basic rules:
careful choose the default behaviour, YAGNI, and the principle of least 
surprise? Certainly not.

IIRC that feature was introduced for such a corner case, where someone
installed a system lib (was it cppunit?) in a strange location (was it 
/opt?) and wanted that LO discover it.

In fact that change introduce some subtle problems even on sane 
platforms, where LD_LIBRARY_PATH is unset:
if one has multiple LO branches on the same machine and try to compile 
it from the same shell:

1. cd libo_3_6_2 && make dev-install
that sources the ooenv and set the LD_LIBRARY_PATH:
grep LD_LIBRARY_PATH ooenv
export LD_LIBRARY_PATH="$thisdir:$java_path:$LD_LIBRARY_PATH"

2. cd libo_master && make dev-install
the behaviour is undefined here, because the artifacts from the wrong LO 
branch are included now in LD_LIBRARY_PATH

That why i would tend to suggest to restore the previous default 
behaviour and honour the system-wide LD_LIBRARY_PATH
only if asked explicitly, say with --enable-honour-ld-library-path 
configure option.

Regards
David