Build Error

[Stephan Bergmann]

On 10/25/2012 08:56 AM, David Ostrovsky wrote:
> 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.

Ah, thanks for that pointer.  That could explain things.

> 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 commit was simply to carry the behavior that had existed in 
the old build system for a very long time over to the new build system, 
where it had looked like an unintentional oversight that the new build 
system's behavior had differed from the old one's in the first place.

I'm undecided here.  On the one hand, it feels bad to "be rude" and 
bluntly override a user's LD_LIBRARY_PATH in our build system.  On the 
other hand, having people run into problems is not what we want, either.

However, I fear that even if we overrode a user's preset LD_LIBRARY_PATH 
completely in those places where we need to set an LD_LIBRARY_PATH in 
our build system, there might still be other places where our build 
system starts to fail mysteriously anyway for an inappropriate setting 
like LD_LIBRARY_PATH=/usr/lib that we would use unmodified in such 
places.  (On Linux, we appear to be somewhat lucky that finding a 
subordinate library via RPATH takes precedence over finding it via 
LD_LIBRARY_PATH.  Solaris does it the other way around IIRC.)

> 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

No, that should not cause any problems, as ooenv should be sourced into 
some sub-process, not the shell process itself that is used to call (1) 
and (2).

> 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.

Oh no, not yet another configure switch, please.  ;)

Stephan