gtk2 fails to link with libXdamage.1.1.0.dylib

[golekipro@…]

I get the following error while doing 'sudo port install easytag'

/usr/bin/nm -p  .libs/gdk.o .libs/gdkapplaunchcontext.o .libs/gdkcairo.o .libs/gdkcolor.o .libs/gdkcursor.o .libs/gdkdisplay.o .libs/gdkdisplaymanager.o .libs/gdkdnd.o .libs/gdkdraw.o .libs/gdkevents.o .libs/gdkfont.o .libs/gdkgc.o .libs/gdkglobals.o .libs/gdkimage.o .libs/gdkkeys.o .libs/gdkkeyuni.o .libs/gdkpango.o .libs/gdkpixbuf-drawable.o .libs/gdkpixbuf-render.o .libs/gdkpixmap.o .libs/gdkpolyreg-generic.o .libs/gdkrectangle.o .libs/gdkregion-generic.o .libs/gdkrgb.o .libs/gdkscreen.o .libs/gdkselection.o .libs/gdkvisual.o .libs/gdkwindow.o .libs/gdkwindowimpl.o .libs/gdkenumtypes.o  x11/.libs/libgdk-x11.a | sed -n -e 's/^.*[    ]\([BCDEGRST][BCDEGRST]*\)[     ][      ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | /usr/bin/sed 's/.* //' | sort | uniq > .libs/libgdk-x11-2.0.exp
/usr/bin/grep -E -e "^[^_].*" ".libs/libgdk-x11-2.0.exp" > ".libs/libgdk-x11-2.0.expT"
mv -f ".libs/libgdk-x11-2.0.expT" ".libs/libgdk-x11-2.0.exp"
rm -fr .libs/libgdk-x11-2.0.lax
mkdir .libs/libgdk-x11-2.0.lax
rm -fr .libs/libgdk-x11-2.0.lax/libgdk-x11.a
mkdir .libs/libgdk-x11-2.0.lax/libgdk-x11.a
Extracting /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_gtk2/work/gtk+-2.14.4/gdk/x11/.libs/libgdk-x11.a
(cd .libs/libgdk-x11-2.0.lax/libgdk-x11.a && ar x /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_gtk2/work/gtk+-2.14.4/gdk/x11/.libs/libgdk-x11.a)
sed 's,^,_,' < .libs/libgdk-x11-2.0.exp > .libs/libgdk-x11-2.0-symbols.expsym
/usr/bin/gcc-4.0 -dynamiclib ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o .libs/libgdk-x11-2.0.0.1400.4.dylib  .libs/gdk.o .libs/gdkapplaunchcontext.o .libs/gdkcairo.o .libs/gdkcolor.o .libs/gdkcursor.o .libs/gdkdisplay.o .libs/gdkdisplaymanager.o .libs/gdkdnd.o .libs/gdkdraw.o .libs/gdkevents.o .libs/gdkfont.o .libs/gdkgc.o .libs/gdkglobals.o .libs/gdkimage.o .libs/gdkkeys.o .libs/gdkkeyuni.o .libs/gdkpango.o .libs/gdkpixbuf-drawable.o .libs/gdkpixbuf-render.o .libs/gdkpixmap.o .libs/gdkpolyreg-generic.o .libs/gdkrectangle.o .libs/gdkregion-generic.o .libs/gdkrgb.o .libs/gdkscreen.o .libs/gdkselection.o .libs/gdkvisual.o .libs/gdkwindow.o .libs/gdkwindowimpl.o .libs/gdkenumtypes.o  .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkapplaunchcontext-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkasync.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkcolor-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkcursor-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkdisplay-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkdnd-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkdrawable-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkevents-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkfont-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkgc-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkgeometry-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkglobals-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkim-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkimage-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkinput-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkinput-xfree.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkinput.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkkeys-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkmain-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkpixmap-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkproperty-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkscreen-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkselection-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkspawn-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdktestutils-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkvisual-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkwindow-x11.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkxftdefaults.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/gdkxid.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/xsettings-client.o .libs/libgdk-x11-2.0.lax/libgdk-x11.a/xsettings-common.o   -L/opt/local/lib -L/usr/X11/lib /opt/local/lib/libpangocairo-1.0.dylib /opt/local/lib/libz.dylib /opt/local/lib/libcairo.dylib /opt/local/lib/libpangoft2-1.0.dylib /opt/local/lib/libpixman-1.dylib /opt/local/lib/libpango-1.0.dylib /opt/local/lib/libgio-2.0.dylib /opt/local/lib/libgobject-2.0.dylib /opt/local/lib/libgmodule-2.0.dylib /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libfontconfig.dylib /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib /usr/X11/lib/libXinerama.1.0.0.dylib /usr/X11/lib/libXi.6.0.0.dylib /usr/X11/lib/libXcursor.1.0.2.dylib /usr/X11/lib/libXrender.1.3.0.dylib /opt/local/lib/libXrender.dylib /usr/X11/lib/libXcomposite.1.0.0.dylib /usr/X11/lib/libXext.6.4.0.dylib /usr/X11/lib/libXdamage.1.1.0.dylib /usr/X11/lib/libXfixes.3.1.0.dylib /usr/X11/lib/libX11.6.2.0.dylib /usr/X11/lib/libXau.6.0.0.dylib /usr/X11/lib/libXdmcp.6.0.0.dylib /opt/local/lib/libtiff.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng12.dylib -lz /opt/local/lib/libjasper.dylib -lm ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.dylib  -Wl,-framework -Wl,CoreServices -Wl,-framework -Wl,ApplicationServices -install_name  /opt/local/lib/libgdk-x11-2.0.0.dylib -compatibility_version 1401 -current_version 1401.4 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libgdk-x11-2.0-symbols.expsym
i686-apple-darwin9-gcc-4.0.1: /usr/X11/lib/libXdamage.1.1.0.dylib: No such file or directory
make[4]: *** [libgdk-x11-2.0.la] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Error: The following dependencies failed to build: gtk2 hicolor-icon-theme
Error: Status 1 encountered during processing.

[jmroot (Joshua Root)]

Looks like the same issue as #14592 (mismatch between .la files and available .dylibs). comment:ticket:17008:3 says the fix is to either delete the .la files in /usr/X11/lib or install a newer XQuartz package.

[golekipro@…]

Agreed, after install XQuartz, easytag compile correctly.

[ryandesign (Ryan Carsten Schmidt)]

This ticket was marked as a duplicate of #14592 but that is a problem with a different library, libXrandr. The file ${x11prefix}/lib/libXrandr.la used to refer to the symlink libXrandr.2.0.0.dylib but that does not exist on clean installs of the current version of Leopard. According to #17008 and LeopardProblems, upgrading to Xcode 3.1 fixes the .la file to correctly refer to libXrandr.2.1.0.dylib instead which does exist, so the problem for that library is resolved.

However the same is not true of libXdamage.1.1.0.dylib, the file of issue in this ticket. Even on Mac OS X 10.5.6 with Xcode 3.1.2, the file ${x11prefix}/lib/libXdamage.la refers to the library libXdamage.1.1.0.dylib which does not exist. The symlink libXdamage.1.0.0.dylib does exist. I did not try installing XQuartz as suggested above because I do not agree that it is a correct solution to force users to install that.

We do have a port xorg-libXdamage in MacPorts now. I do not know if that would perhaps be part of an appropriate fix. Or, if as Jeremy said in #17008, the true bug is that the system's .la file refers to the wrong library version, then the port should check for this and explain to the user how to fix the libXdamage.la file if necessary.

[jeremyhu (Jeremy Huddleston Sequoia)]

It's the same issue even though it's a different file.

If you want my opinion on what the right solution is, I'd say a global

post-destroot {
    rm ${prefix}/lib/*.la
}

or whatever the tcl is for that.

The main issue is an Apple issue and not something that can be fixed by Macports. I'm not sure why the Xcode 3.1.2 .la files are back to referring to the full-versioned file, but that's wrong, and I'll look into it...

[jeremyhu (Jeremy Huddleston Sequoia)]

BTW, the semi-official party line is something like this:

This issue will hopefully be solved in a future OSX release, but due to technical reasons will most likely not be addressed in a Software Update to Leopard nor an update to XCode for Leopard. As a workaround for this issue, developers are encouraged to use the MacOSX10.5.sdk (/Developer/SDKs/MacOSX10.5.sdk) which does not contain the libtool-archive files. If that is not an option, developers are encouraged to either delete the libtool-archive files on their system (since they provide redundant information already present in the dylibs themselves) or use a release from ​http://xquartz.macosforge.org which contains consistent libtool-archive files.

So if users go +universal, then they automagically avoid the problem...

[ryandesign (Ryan Carsten Schmidt)]

We shouldn't be requiring our users to build +universal, especially since so much of our ports tree still doesn't build +universal at this time.

If the recommended fix is to remove /usr/X11/lib/*.la then I cannot see why there is any technical barrier to Apple releasing a 10.5.x software update to do so. Apple could have non-technical reasons for not wanting to do so, and it would certainly not be without precedent for Apple to punt bug fixes to the next paid version of Mac OS X.

The gtk2 port could also take it upon itself to remove /usr/X11/lib/libXdamage.la on Leopard if present, or maybe better, rename it. That would also fix the issue, wouldn't it? It would have to happen pre-configure at the latest, I imagine; post-destroot is too late, since the failure occurs in the build phase already.

[jeremyhu (Jeremy Huddleston Sequoia)]

I wasn't suggesting we force users to adopt +universal... I was just making an observation...

The technical barrier to removing /usr/X11/lib/*.la is that those files aren't actually part of the OS. They're shipped with XCode, so even if a SU removes them, the user can just reinstall them again by reinstalling XCode... =/ There was a huge discussion on this a few months ago on xquartz-dev if you want to dig it up, but it essentially comes down to there not being a good solution for Leopard becasue even if we do stop shippment of the .las in Xcode and force-delete them if they exist in a SU, we still have a problem in that all the .las in Macports actually refer by filename to the .las in /usr/X11/lib ... so that would break existing .las in macports and fink (In fact it was eitehr a fink or macports dev at the time that vehemently opposed that as a solution)

Removing the .la in gtk2 itself wouldn't really fix the problem either because it's possible that something else in macports (or fink or gentoo or /usr/local or ...) refers to that .la (the same reason why we're not removing them in a SU) ...

The best solution, IMO, is to 'find / -name '*.la' -exec rm {} \;' ... but that's not quite an option... /sigh...

[jeremyhu (Jeremy Huddleston Sequoia)]

Of course another short-term solution is to figure out why these las in XCode have a weird reference... They should have:

dlname='libXdamage.1.dylib'

but from what you say, it sounds like they're:

dlname='libXdamage.1.1.0.dylib'

Is that right?

Perhaps as a macports solution we could do a 'reinplace ...' for that change.

[ryandesign (Ryan Carsten Schmidt)]

Not quite... I have:

$ ls -l /usr/X11/lib/libXdamage*
lrwxr-xr-x  1 root  wheel     18 Jul  3 15:49 /usr/X11/lib/libXdamage.1.0.0.dylib -> libXdamage.1.dylib
-rwxr-xr-x  1 root  wheel  88448 Jul 31 20:57 /usr/X11/lib/libXdamage.1.dylib
lrwxr-xr-x  1 root  wheel     18 Jul  3 15:49 /usr/X11/lib/libXdamage.dylib -> libXdamage.1.dylib
-rwxr-xr-x  1 root  wheel    936 May 10  2008 /usr/X11/lib/libXdamage.la

But:

$ grep dylib /usr/X11/lib/libXdamage.la
dlname='libXdamage.1.dylib'
library_names='libXdamage.1.dylib libXdamage.dylib libXdamage.1.1.0.dylib'

So it's not dlname but library_names that's wrong. But as you say we could perhaps reinplace that file to fix it. Then again, so could an Apple update (be it a Mac OS X update or an Xcode update).

Then again, if it references the wrong library name, and clearly gtk2 fails to compile as a result, how could any other port have successfully compiled against that library? And if there is thus no MacPorts library linking with that .la, we could again delete it, if that is the generally agreed-upon fix.

[jeremyhu (Jeremy Huddleston Sequoia)]

The problem is that the other port compiled in the past when it was correct, the .la file for that installed port references /usr/X11/lib/libXdamage.la. If we nuke the .la, then anything linking against that existing-port using glibtool will fail. If instead that existing port is recompiled, then its libtool file will use '-lXdamage' instead of '/usr/X11/lib/libXdamage.la'

That's weird that glibtool is using library_names rather than dlname... I was operating under the assumption this entire time that the dlname was wrong in earlier Xcode releases and that was the problem...

[blb@…]

Cc reporter of dup #17857.

[ryandesign (Ryan Carsten Schmidt)]

So, to summarize, the error message is:

i686-apple-darwin9-gcc-4.0.1: /usr/X11/lib/libXdamage.1.1.0.dylib: No such file or directory

And this is true; Apple provides no libXdamage.1.1.0.dylib. Apple provides libXdamage.1.0.0.dylib. But with it, Apple provides a libXdamage.la which says:

library_names='libXdamage.1.dylib libXdamage.dylib libXdamage.1.1.0.dylib'

To fix the problem, all I have to do is change this line in libXdamage.la to read:

library_names='libXdamage.1.dylib libXdamage.dylib libXdamage.1.0.0.dylib'

So, when can we expect the Apple update that fixes this Apple file to show the correct version number of this Apple library? :)

[jeremyhu (Jeremy Huddleston Sequoia)]

ryan: It's not that trivial. The dylib and la files are part of different packages updated differently (XCode versus SU). The XCode version needs to work with any OS release. Perhaps the better fix which we could do in Xcode would be to just drop the last filename, so it would be:

library_names='libXdamage.1.dylib libXdamage.dylib'

Could you try that for me?

On a side note, this problem should be going away for most users in the next couple days with the lib: -> port: dependency changes for X11...

[jeremyhu (Jeremy Huddleston Sequoia)]

r45603 should solve the problem for users not setting +system_x11 variant. ryan, I know you're already using the system_x11 variant, so could you please respond to my previous query and if that works, I'll try to get it into an XCode update.

[blb@…]

Cc reporter of dup #18089.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

r45603 should solve the problem for users not setting +system_x11 variant. ryan, I know you're already using the system_x11 variant, so could you please respond to my previous query and if that works, I'll try to get it into an XCode update.

I have never selected the +system_x11 variant; when the ports switched to using MacPorts X11 the problem was hidden from me, and I have not wanted to break my system again by trying the +system_x11 variant.

[(none)]

Milestone Port Bugs deleted

[nox@…]

That has been fixed since the last ticket update, right?

[ryandesign (Ryan Carsten Schmidt)]

Yes, in that the problem can no longer occur for MacPorts because we no longer ever try to use the system's X11.