[Libreoffice] dyld install_name: Re: What do we want from extensions module?

[Michael Stahl]

On 18/12/11 12:05, Christian Lohmaier wrote:
> Hi Michel, *,
> 
> On Sun, Dec 18, 2011 at 2:39 AM, Michael Stahl <mstahl at redhat.com> wrote:
>> On 14/12/11 23:28, Peter Foley wrote:
>>> On Wed, 14 Dec 2011, Michael Stahl wrote:
>> [...]
>> - the spotlight plugin:
>>  no idea if that will actually work;
>>  i really hope we use the system zlib always on MacOS X, because
>>  the old makefile had this horrible thing in it:
>>
>> # we have to change the zlib install name, otherwise the plugin will not
>> work
>>    .IF "$(SYSTEM_ZLIB)"=="NO"
>>    install_name_tool -change @executable_path/libz.1.dylib
>> @executable_path/../../../../MacOS/libz.1.dylib
>> $(MACOS)$/OOoSpotlightImporter
>>    .ENDIF
> 
> Is changing the installname what you call "horrible thing"? Then you
> might be surprised that this is not a scary thing at all. *all* LO
> libs go through this.
> http://opengrok.libreoffice.org/xref/core/solenv/inc/unxmacx.mk#175
> http://opengrok.libreoffice.org/xref/core/solenv/gbuild/platform/macosx.mk#145
> http://opengrok.libreoffice.org/xref/core/solenv/bin/macosx-change-install-names.pl

argh, don't remind me :)

i was thinking that it could be a problem because (as i found out by
downloading and mounting the instset dmg on linux) the spotlight
importer is located in a separate directory
"Contents/Library/Spotlight/OOoSpotlightImporter.mdimporter/Contents/MacOS/",
and currently this install name hackery doesn't handle that case, and
i'd rather not touch that.

> There is no concept of a library search path on Mac, all libs
> explicitly reference the libs they depend on.By absolute paths or
> relative to the specials executable_path and loader_path
> 
> I also suggest to read the tinderbox mails.

i usually don't read my work mail account on weekends, so i didn't
notice that the failure in instsetoo_native was actually caused by
salhelper; would it be possible for tinderboxes to detect that a build
failed in instsetoo_native and then upload the hidden second log file
that has the actual reason somewhere?

> As just removing what
> seems like a hack to you without providing the "proper" solutin
> (whatever that might have been in your idea) did broke the build. (the
> salhelper filename dylib.3 vs just dylib - Norbert did revert that
> commit today)

yeah, sorry i failed to remember why exactly i wrote
gb_LinkTarget__get_installname way back in
dbd21fcb53f6e38e83dbb5aca521a97482ee0e85  :)

i'll have another try, perhaps this untested change works better:
a0a21ffa5b4198735823802e4ab516120393609c

> ciao
> Christian

PS: please let your mac tinderbox have a go at
feature/gbuild_extensions, i'm pretty sure it will break but am curious
how  :)