Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#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)

Portfile.diff (1.1 KB) - added by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) 15 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 15 years ago by mf2k (Frank Schima)

Owner: changed from macports-tickets@… to nox@…
Port: gtk2hs added

Assigning to maintainer.

comment:2 Changed 15 years ago by jmroot (Joshua Root)

Port: gtk2 added; gtk2hs removed

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

comment:3 Changed 15 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 15 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 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attachment: Portfile.diff added

comment:5 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… added

Cc Me!

comment:6 Changed 15 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 15 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 Changed 15 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 15 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 in reply to:  8 Changed 15 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 in reply to:  3 Changed 15 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 in reply to:  6 ; Changed 15 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 15 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 in reply to:  12 ; Changed 15 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 in reply to:  14 Changed 15 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:16 Changed 15 years ago by afb@…

Cc: afb@… added

Cc Me!

comment:17 Changed 15 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 15 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 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: newclosed

Fixed in r41528.

comment:20 Changed 15 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

Note: See TracTickets for help on using tickets.