Thank you very much for your bug report!


This time, the crash log is really interesting; it says:

> Application Specific Information:
> dyld: launch, loading dependent libraries
> 
> Dyld Error Message:
>   Library not loaded: /usr/local/lib/libiconv.2.dylib
>   Referenced from: /Applications/LOdev.app/Contents/MacOS/liblangtag.0.dylib
>   Reason: Incompatible library version: liblangtag.0.dylib requires version
>     8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

This is quite clear, the only question is: which developer does know best about liblangtag?

I will try to reproduce this bug later (no doubt that it *is* reproducible ;-).

REPRODUCIBLE with current master build,
date: 2012-08-23 23:44:16,
installation file:
master~2012-08-23_23.44.16_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US,
on MacOS X 10.6.8 (Intel).

Naturally, installing the US English language pack does not change the situation.

The error message is exactly the same for me, which is interesting given the fact that Joren De Cuyper uses MacOS X 10.8.1, and I use 10.6.8:

> Dyld Error Message:
>   Library not loaded: /usr/local/lib/libiconv.2.dylib
>   Referenced from: /Applications/LOdev/LOdev.app/Contents/MacOS
      /liblangtag.0.dylib
>   Reason: Incompatible library version: liblangtag.0.dylib requires version
>     8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

IIRC, this bug was NOT present in the master build from 2012-08-21 (LibreOffice 3.7.0.0.alpha0+, Build ID: 9e04ae0), which starts normally on my machine.

So introduced between August 21 and August 23?!

@Eike Rathke, Stephan Bergmann, and Tor Lillqvist:

I am not sure who knows best about liblangtag, therefore I CC you all about this bug related to liblangtag, because you have made some commits related to liblangtag in the past.

Please take a look at this issue. If the error message is right (I hope it is), the problem is that liblangtag.0.dylib now requires libiconv version 8.0.0 or later, but the local libiconv.2.dylib on MacOS X (10.6.8 to 10.8.1) provides only version 7.0.0.

This bug prevents the currect master build from starting, so testing the master builds is impossible now on MacOS X. Therefore we need a fix for this issue ...


@Thorsten Behrense:

you are our MacOS X expert, so please help the others with this issue, if necessary.


Thank you all very much in advance!

The bug is already in this build:
master~2012-08-22_22.21.58_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US

Identical error message.

Confirmed: this bug was NOT present in master~2012-08-21_00.09.17_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US, build-id: 9e04ae0

Therefore bug introduced between 2012-08-21 00:09:17 (pull time) and 2012-08-22 22:21:58 (pull time).

This is all I can do to help, being a simple-minded bugwrangler. If I can help anything else to fix this bug, just let me know. Thanks!

I wouldn't like to spam but the problem is still reproducable with 
'master~2012-08-25_11.31.18_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US'.

So can it really be that older Mac OS X versions provide a libiconv with a newer version number? Or is the code built (accidentally?) against some other libiconv than the system one? The TDF build of LO includes the Mozilla stuff, and that requires all kind of extra crack, right? Is it likely that it then gets built against a libiconv that is part of that, but said libiconv is not included in the distributed LO?

(In reply to comment #8)
> So can it really be that older Mac OS X versions provide a libiconv with a
> newer version number?

Strange indeed. Well, according to the Dyld error messages, both on MacOS X 10.8.1 (see comment #1) and on 10.6.8 (see comment #2), "libiconv.2.dylib provides version 7.0.0", so the _same_ version on both systems.


I tried to find out which version of libiconv is really present on my system (10.6.8), but with limited succss.

1) At /usr/local/lib (the location mentioned in the error messages), there is NO libiconv stuff at all. This not very surprising, of course.

Could it be that simple that LibO now tries to load libiconv from the wrong path, I mean, /usr/local/lib instead of /usr/lib ?


2) At /usr/lib, we find:
  libiconv.2.dylib      : date 2010-02-11
  libiconv.dylib        : link/alias to libiconv.2.dylib
  libiconv.2.4.0.dylib  : link/alias to libiconv.2.dylib

I can’t find any human readably version string inside of libiconv.2.dylib.


3) When I type
  iconv --version
into the terminal, I get this (not very helpful) answer:
  iconv (GNU libiconv 1.11)
  Copyright (C) 2000-2006 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  Written by Bruno Haible.


4) The documentation at
  http://www.gnu.org/software/libiconv/
does not tell anything about version history (at least I can't find it).

Ah, I didn't looke at the second comment closely enough; that /usr/local indeed is a sign that something from the *build system* that is peculiar to that got pipcked up, hopefully unintentionally. Is/was there a /usr/lib/libiconv.dylib also in MacOSX 10.[45] ?

The problem appears to be fixed in :

Version 3.7.0.0.alpha0+ (Build ID: 3e9f9e5)

from master build 27/08, the app starts normally on my OSX 10.8 machine

Alex

(In reply to comment #10)
> Is/was there a /usr/lib/libiconv.dylib also in MacOSX 10.[45] ?

From a quick web search over some forums, I get the impression that
* MacOS X 10.4.x includes libiconv.2.dylib version 5.0.0
* MacOS X 10.6.x includes libiconv.2.dylib version 7.0.0

(In reply to comment #11)
> The problem appears to be fixed in :
> Version 3.7.0.0.alpha0+ (Build ID: 3e9f9e5)
> from master build 27/08, the app starts normally on my OSX 10.8 machine

Nice to hear! But my results are different:
If I install the latest build, i.e.

master~2012-08-27_05.09.55_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg

on my MacOS X 10.6.8 machine, I still get the same error report at startup:

> Dyld Error Message:
>   Library not loaded: /usr/local/lib/libiconv.2.dylib
>   Referenced from: /Applications/LOdev.app/Contents/MacOS/liblangtag.0.dylib
>   Reason: Incompatible library version: liblangtag.0.dylib requires version
>     8.0.0 or later, but libiconv.2.dylib provides version 7.0.0


@ Alex:
Do you have any version of libiconv.2.dylib installed at /usr/local/lib/ ?

@ Joren De Cuyper:
What are your results -- can you start the master build 27/08?

> @ Joren De Cuyper:
> What are your results -- can you start the master build 27/08?

Negative... I also can't start it with this version ... The problem isn't solved :(.

(master~2012-08-27_05.09.55_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US)

(In reply to comment #13)
> (In reply to comment #11)


> @ Alex:
> Do you have any version of libiconv.2.dylib installed at /usr/local/lib/ ?


MacBookPro:~ alex$ locate libiconv.2.dylib
/Applications/DVDStyler.app/Contents/libs/libiconv.2.dylib
/Applications/Games/Nexuiz/extra/NetRadiant-1.5.0-svn389-osxintel.app/Contents/MacOS/install/libiconv.2.dylib
/Applications/Gimp.app/Contents/Resources/lib/libiconv.2.dylib
/Applications/Hugin/Hugin.app/Contents/Libraries/libiconv.2.dylib
/Applications/Inkscape.app/Contents/Resources/lib/libiconv.2.dylib
/Applications/MAMP/Library/lib/libiconv.2.dylib
/Applications/MAMP_2012-07-12_16-46-17/Library/lib/libiconv.2.dylib
/Applications/MDB Explorer.app/Contents/Frameworks/libiconv.2.dylib
/Applications/MacPorts/AbiWord.app/Contents/Frameworks/libiconv.2.dylib
/Applications/MacPorts/pgAdmin3.app/Contents/Frameworks/libiconv.2.dylib
/Applications/Scribus.app/Contents/Frameworks/libiconv.2.dylib
/Applications/Stellarium.app/Contents/Frameworks/i386/libiconv.2.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/libiconv.2.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libiconv.2.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/usr/lib/libiconv.2.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.1.sdk/usr/lib/libiconv.2.dylib
/Applications/luminance.app/Contents/Frameworks/libiconv.2.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libiconv.2.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libiconv.2.dylib
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libiconv.2.dylib
/opt/local/lib/libiconv.2.dylib
/usr/lib/libiconv.2.dylib
/usr/local/lib/libiconv.2.dylib
/usr/local/php5/lib/libiconv.2.dylib

and iconv --version gives :
iconv (GNU libiconv 1.13)
Copyright (C) 2000-2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Écrit pas Bruno Haible.

Alex

(In reply to comment #15)


lsof /usr/local/lib/libiconv.2.dylib

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
gpg-agent 1083 alex  txt    REG    1,2  2004008 2349429 /usr/local/lib/libiconv.2.dylib

@ Alex Thurgood:
Thank you for all the details!

-> So the current master builds work, if libiconv.2.dylib is installed at /usr/local/lib/ and is of version 8.0.0 or better ("iconv --version" gives a number >= 1.12). Right?

IMHO this confirm Tor's idea:

(In reply to comment #10)
> ... that /usr/local indeed is a sign that something from the *build system*
> that is peculiar to that got pipcked up, hopefully unintentionally.

@Norbert:
Because you are providing the daily builds for MacOS X, maybe you can figure out what’s wrong with them since a few days? Please take a look at this bug report. At the moment, some of us (Joren de Cuyper, me, and probably others) can’t test the daily builds at all because of this issue. Maybe this a problem with the build system, see comment #10 ...

Thank you very much in advance!


(And sorry to all the others that I did not think earlier about asking Norbert!)

(In reply to comment #6)
> Confirmed: this bug was NOT present in
> master~2012-08-21_00.09.17_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US,
> build-id: 9e04ae0
> 
> Therefore bug introduced between 2012-08-21 00:09:17 (pull time) and 2012-08-22
> 22:21:58 (pull time).
> 
> This is all I can do to help, being a simple-minded bugwrangler. If I can help
> anything else to fix this bug, just let me know. Thanks!

A bit late, but I can CONFIRM that this bug is NOT present in master~2012-08-21_00.09.17_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US (build-id: 9e04ae0)

Workaround:

If I manually copy some up-to-date version of "libiconv.2.dylib" (e.g., from GIMP 2.8.0 -- Gimp.app/Contents/Resources/lib/libiconv.2.dylib) to
    /usr/local/lib
and create a symbolic link "libiconv.2.dylib" in the same directory which points to the new copy of "libiconv.2.dylib" there, I can start and use LOdev again.

But this is a workaround, not a fix ;-), it is not suitable for everybody (most Mac OS users are still not used to copy files to hidden directories, and /usr/local/lib _is_ hidden ;-), and just shows that this is really a rather "simple" problem with wrong assumptions about libiconv version and installation at /usr/local/lib.

So, it should be possible to fix this, shouldn’t it? Thanks!

I think there is little point discussing this any further, as it is quite clear what the problem is, we now just wait for somebody to fix it.

I'm looking into it

Should be fixed for daily build generated by @1

but this is 'fixed by hiding the problem...' really liblangtag on Mac should never use pkg-config, even if one is present, to find a glib2 and should always use the internal one instead

I can confirm; new masterbuild starts normally.

master~2012-08-31_04.36.39_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US

Is this the final fix; or did you just 'hide the problem'?

Thanks for your time anyway,
Joren

Verified by me, so Status -> VERIFIED/FIXED.

(In reply to comment #23)
> but this is 'fixed by hiding the problem...' really liblangtag on Mac should
> never use pkg-config, even if one is present, to find a glib2 and should always
> use the internal one instead

You can avoid using pkg-config by simply setting following env variables during the configure:
  GOBJECT_CFLAGS
              C compiler flags for GOBJECT, overriding pkg-config
  GOBJECT_LIBS
              linker flags for GOBJECT, overriding pkg-config
  GMODULE_CFLAGS
              C compiler flags for GMODULE, overriding pkg-config
  GMODULE_LIBS
              linker flags for GMODULE, overriding pkg-config