gtk2 port incorrectly advises users to make a symlink

[jeremyhu@…]

There is no need to force users to make this symlink... please remove this from the port.

Warning: the following items did not execute (for unrar): org.macports.destroot org.macports.build
Error: Unable to upgrade port: 1
--->  Fetching gtk2
Error: Some libs are missing from your X11 installation. Please run this command:
Error: sudo ln -s libXrandr.2.dylib /usr/X11/lib/libXrandr.2.0.0.dylib
Error: Target org.macports.fetch returned: missing /usr/X11/lib/libXrandr.2.0.0.dylib
Warning: the following items did not execute (for gtk2): org.macports.destroot org.macports.fetch org.macports.extract org.macports.checksum org.macports.patch org.macports.configure org.macports.build
Error: Unable to upgrade port: 1
--->  Fetching gtk2
Error: Some libs are missing from your X11 installation. Please run this command:
Error: sudo ln -s libXrandr.2.dylib /usr/X11/lib/libXrandr.2.0.0.dylib
Error: Target org.macports.fetch returned: missing /usr/X11/lib/libXrandr.2.0.0.dylib
Warning: the following items did not execute (for gtk2): org.macports.destroot org.macports.fetch org.macports.extract org.macports.checksum org.macports.patch org.macports.configure org.macports.build
Error: Unable to upgrade port: 1

(10:52:00 Sun Oct 26 2008 jeremy@tifa i386)
~/src/apple/X11_quartz_wm/trunk $ ls -l /usr/X11/lib/libXrandr.*
lrwxrwxrwx 1 root wheel     17 2008-10-22 18:41 /usr/X11/lib/libXrandr.2.1.0.dylib -> libXrandr.2.dylib
-rwxr-xr-x 1 root wheel 134276 2008-10-22 16:53 /usr/X11/lib/libXrandr.2.dylib
lrwxrwxrwx 1 root wheel     17 2008-10-22 18:41 /usr/X11/lib/libXrandr.dylib -> libXrandr.2.dylib
-rwxr-xr-x 1 root wheel    955 2008-10-22 16:52 /usr/X11/lib/libXrandr.la

[macsforever2000@…]

Assigning to maintainer.

[jmr@…]

The check and symlink advice was added because of #14592.

[jeremyhu@…]

Well that was the wrong resolution for #14592 ... that bug resulted because the user had .la files that referred to the wrong .dylib. This is a problem on the default Leopard X11, and there are two solutions:

1) nuke all the .la files on the system (preferred, and what is happening with SnowLeopard) 2) Install  http://xquartz.macosforge.org over the system X11 since it contains consistent .la files

[mcalhoun@…]

With a clean install of XQuartz, there is no libXrandr.2.0.0.dylib.
This is not an error, but, as noted in the original comments, glib2 will not build.

Attached is a proposed fix.
Since glib2 is listed as openmaintainer, I can make the change easily enough if there are no objections.

The new glib2 just removes the offending code.
I can add an entry LeopardProblems section of the Wiki in case some future user runs into the problem.
Having never run into this, let me make sure I understand:

• The problem arises on certain default Leopard X11 installations.
• The problem can be solved by upgrading to the latest XQuartz (or does one have to delete the .la files first?).

[mcalhoun@…]

Cc Me!

[jeremyhu@…]

yes, it will build. The problem is *NOT* a missing libXrandr.2.0.0.dylib. The problem is that the original reporter's libXrandr.la referenced libXrandr.2.0.0.dylib. After installing X11-2.3.1, you'll notice that libXrandr.la refers to the correct dylib.

I am in favor of punting the first hunk, but you should leave 'lib:libXrender.1:xrender' in place and not pull in the port if the user has libXrender already.

[mcalhoun@…]

Leaving 'lib:libXrender.1:xrender' is fine with me.
It would mean the revision could stay the same.

Just out of curiosity, isn't this a small violation of the "MacPorts uses its own libraries" policy?

[jeremyhu@…]

Isn't the policy that Macports uses its own libraries unless those libraries are supplied by OSX? We've had issues reported to the x11-users mailing list multiple times over the past year while I've been maintaining X11, and frequently it comes down to their using a Macports lib over one included with X11.

Based on your earlier comment, I'm guessing this is partly due to lack of maintainers. I just now tried to pull in some X11 packages and they fail because of the xmkmf removal and the old version of autoconf used to build configure in the package (those packages just need you to 'reautoconf' or pass '--x-include=/usr/X11/include --x-lib=/usr/X11/lib' to configure. I'd be willing to help out with some of these packages if maintainership is the issue...

[mcalhoun@…]

All I have to go on is the documentation ( http://trac.macports.org/wiki/FAQ#WhyisMacPortsusingitsownlibraries), but the rule seems to be:
use MacPorts libraries unless there is a good reason not to.
An exempt port might be, e.g., Kerberos (#14775).

X11 seems to be somewhere in the middle.
Of the ports which depend on xrender, only two (gtk2 and teg) use 'lib:libXrender:xrender'.
The rest use 'port:xrender'.

As for the lack of xmkmf, I ran into the same problem when I tried to install Xaw3d.
I wrote an imake package, but I have not submitted it yet.

[blb@…]

Replying to jeremyhu@…:

Isn't the policy that Macports uses its own libraries unless those libraries are supplied by OSX? We've had issues reported to the x11-users mailing list multiple times over the past year while I've been maintaining X11, and frequently it comes down to their using a Macports lib over one included with X11.

The opposite actually, MacPorts prefers depending on bits from MacPorts when possible; there are of course some exceptions, X11 being one of them.

Based on your earlier comment, I'm guessing this is partly due to lack of maintainers. I just now tried to pull in some X11 packages and they fail because of the xmkmf removal and the old version of autoconf used to build configure in the package (those packages just need you to 'reautoconf' or pass '--x-include=/usr/X11/include --x-lib=/usr/X11/lib' to configure. I'd be willing to help out with some of these packages if maintainership is the issue...

I believe many of the X11 ports are in fact unmaintained at the moment, and some have maintainers but seem to be experiencing some severe bitrot.

[afb@…]

Replying to jeremyhu@…:

Well that was the wrong resolution for #14592 ... that bug resulted because the user had .la files that referred to the wrong .dylib. This is a problem on the default Leopard X11, and there are two solutions: 1) nuke all the .la files on the system (preferred, and what is happening with SnowLeopard) 2) Install  http://xquartz.macosforge.org over the system X11 since it contains consistent .la files

But installing the compat symlink is much easier/unintrusive than deleting libtool files and/or installing development versions (Xquartz) of the system X11... I don't think it's any uglier than the /usr/X11R6 -> X11 compat symlink.

[afb@…]

Replying to jeremyhu@…:

yes, it will build. The problem is *NOT* a missing libXrandr.2.0.0.dylib. The problem is that the original reporter's libXrandr.la referenced libXrandr.2.0.0.dylib. After installing X11-2.3.1, you'll notice that libXrandr.la refers to the correct dylib.

Problem isn't the libtool file itself (it's updated with X11), it's rebuilding all random MacPorts libraries that were linking with the previous minor version of the library. And doing so with only the limited dependencies that MP offers.

[nox@…]

Bellcross:~ nox$ cat /usr/X11/lib/libXrandr.la | grep dlname
dlname='libXrandr.2.dylib'
Bellcross:~ nox$ ls -l /usr/X11/lib/libXrandr.2.dylib 
-rwxr-xr-x  1 root  wheel  164144  1 aoû 03:57 /usr/X11/lib/libXrandr.2.dylib

Maybe we should just delete the advice as it seems the la file is now consistent (I have Apple X11)?

[jeremyhu@…]

Replying to afb@…:

Replying to jeremyhu@…:

yes, it will build. The problem is *NOT* a missing libXrandr.2.0.0.dylib. The problem is that the original reporter's libXrandr.la referenced libXrandr.2.0.0.dylib. After installing X11-2.3.1, you'll notice that libXrandr.la refers to the correct dylib.

Problem isn't the libtool file itself

Yes, it is.

(it's updated with X11)

Not exactly. It is updated with X11 from  http://xquartz.macosforge.org, but it is not updated with OSX Software Update (which is what updated the lib).

, it's rebuilding all random MacPorts libraries that were linking with the previous minor version of the library. And doing so with only the limited dependencies that MP offers.

No... I'm not even sure what you mean by this last sentence.

[afb@…]

Replying to jeremyhu@…:

Problem isn't the libtool file itself

Yes, it is.

(it's updated with X11)

Not exactly. It is updated with X11 from  http://xquartz.macosforge.org, but it is not updated with OSX Software Update (which is what updated the lib).

I updated with SU, and the .la is OK ? Unless there is another file beyond just the libXrandr.la ?

# Names of this library.
library_names='libXrandr.2.dylib libXrandr.dylib libXrandr.2.1.0.dylib'

Presumably the Xquartz releases will eventually be released in a future Mac OS X system update, anyway.

, it's rebuilding all random MacPorts libraries that were linking with the previous minor version of the library. And doing so with only the limited dependencies that MP offers.

No... I'm not even sure what you mean by this last sentence.

With another dependency engine, you could probe for all packages that "require" libXrandr.2.0.0.dylib and trigger a rebuild/reinstall of those packages. With MacPorts, there are no such built-in features so it needs to be hunted down manually. Which most users won't do...

But when all such outdated dependencies are gone there is no need for the workaround anymore, sure.

[afb@…]

Cc Me!

[afb@…]

Sorry, it wasn't Software Update - it was Xcode 3.1. The X11SDK.pkg package had an updated version...

If user installed Xcode 3.0 on a newer system (like 10.5.2) then it would refer to a missing library. But had the system been updated from 10.5.0, then the old library would still be there (as a symlink).

Since newer Macs came with newer preinstalls, we started seeing the problem in the beginning of 2008.

[aronnax@…]

I am seeing this bug on a new Mac Mini. I am trying to install the port for OpenCV but can't because of the dependency on gtk2. What should I do?

[mcalhoun@…]

Fixed in r41528.

[anonymous]

Milestone Port Bugs deleted