Bug 54023 - CRASH on launch when loading local libiconv.2.dylib ("liblangtag.0.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0")
Summary: CRASH on launch when loading local libiconv.2.dylib ("liblangtag.0.dylib requ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: Other macOS (All)
: medium critical
Assignee: Norbert Thiebaud
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-08-24 20:01 UTC by Jorendc
Modified: 2012-09-13 15:25 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Crash Console log (70.04 KB, application/rtf)
2012-08-24 20:01 UTC, Jorendc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorendc 2012-08-24 20:01:55 UTC
Created attachment 66082 [details]
Crash Console log

After installing the LibreOffice 'master~2012-08-23_23.44.16_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg' on my Mac OSX 10.8.1, LibreOffice crashes on startup. I even saw no splashscreen.

Expectation: LibreOffice launch normal and show the splashscreen.

Specification:
Mac OSX 10.8.1; LibreOffice 3.7.0.0.Alpha; No Language package.
Comment 1 Roman Eisele 2012-08-25 07:22:42 UTC
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 ;-).
Comment 2 Roman Eisele 2012-08-25 07:58:47 UTC
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
Comment 3 Roman Eisele 2012-08-25 08:00:39 UTC
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?!
Comment 4 Roman Eisele 2012-08-25 08:09:04 UTC
@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!
Comment 5 Roman Eisele 2012-08-25 08:23:34 UTC
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.
Comment 6 Roman Eisele 2012-08-25 08:35:41 UTC
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!
Comment 7 Jorendc 2012-08-25 22:51:18 UTC
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'.
Comment 8 Don't use this account, use tml@iki.fi 2012-08-27 06:12:28 UTC
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?
Comment 9 Roman Eisele 2012-08-27 09:20:27 UTC
(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).
Comment 10 Don't use this account, use tml@iki.fi 2012-08-27 09:29:44 UTC
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] ?
Comment 11 Alex Thurgood 2012-08-27 10:13:52 UTC
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
Comment 12 Roman Eisele 2012-08-27 10:21:15 UTC
(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
Comment 13 Roman Eisele 2012-08-27 10:34:58 UTC
(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?
Comment 14 Jorendc 2012-08-27 10:55:14 UTC
> @ 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)
Comment 15 Alex Thurgood 2012-08-27 13:12:26 UTC
(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
Comment 16 Alex Thurgood 2012-08-27 13:16:00 UTC
(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
Comment 17 Roman Eisele 2012-08-28 07:16:57 UTC
@ 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.
Comment 18 Roman Eisele 2012-08-28 12:27:38 UTC
@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!)
Comment 19 Jorendc 2012-08-28 18:24:17 UTC
(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)
Comment 20 Roman Eisele 2012-08-30 08:08:45 UTC
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!
Comment 21 Don't use this account, use tml@iki.fi 2012-08-30 08:47:05 UTC
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.
Comment 22 Norbert Thiebaud 2012-08-30 15:07:35 UTC
I'm looking into it
Comment 23 Norbert Thiebaud 2012-08-31 05:25:01 UTC
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
Comment 24 Jorendc 2012-08-31 20:47:15 UTC
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
Comment 25 Roman Eisele 2012-09-13 14:53:53 UTC
Verified by me, so Status -> VERIFIED/FIXED.
Comment 26 Fridrich Strba 2012-09-13 15:25:55 UTC
(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