Build Error
David Ostrovsky
david.ostrovsky at gmx.de
Wed Oct 24 23:56:27 PDT 2012
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
More information about the LibreOffice
mailing list