#17008 closed defect (fixed)
gtk2 port incorrectly advises users to make a symlink
Reported by: | jeremyhu (Jeremy Huddleston Sequoia) | Owned by: | nox@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.6.0 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), afb@… | |
Port: | gtk2 |
Description
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
Attachments (1)
Change History (21)
comment:1 Changed 16 years ago by mf2k (Frank Schima)
Owner: | changed from macports-tickets@… to nox@… |
---|---|
Port: | gtk2hs added |
comment:2 Changed 16 years ago by jmroot (Joshua Root)
Port: | gtk2 added; gtk2hs removed |
---|
The check and symlink advice was added because of #14592.
comment:3 follow-up: 11 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
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
comment:4 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
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?).
Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Attachment: | Portfile.diff added |
---|
comment:5 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | mcalhoun@… added |
---|
Cc Me!
comment:6 follow-up: 12 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
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.
comment:7 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
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?
comment:8 follow-up: 10 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
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...
comment:9 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
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.
comment:10 Changed 16 years ago by 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.
comment:11 Changed 16 years ago by 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.
comment:12 follow-up: 14 Changed 16 years ago by 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.
comment:13 Changed 16 years ago by 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)?
comment:14 follow-up: 15 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
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.
comment:15 Changed 16 years ago by 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.
comment:17 Changed 16 years ago by 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.
comment:18 Changed 16 years ago by 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?
comment:19 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in r41528.
Assigning to maintainer.