#18093 closed defect (fixed)
imake-using ports use wrong X11 libraries when using system xmkmf instead of imake port
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.7.0 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), jeremyhu (Jeremy Huddleston Sequoia), fenner@…, mdales@…, pguyot (Paul Guyot), qbarnes@…, takanori@…, jjstickel@… | |
Port: | canna emiclock fvwm glut kinput2 kinput2-macim kxterm magicpoint spim sunclock tgif tightvnc transfig vtwm wmclock Xaw3d xcb xearth xfig xsnow xspringies xtu |
Description
MacBook Pro, Mac OS X 10.5.6, Xcode 3.1.1, MacPorts 1.7.0, using the patch from #15514:
---> Fetching Xaw3d ---> Verifying checksum(s) for Xaw3d ---> Extracting Xaw3d ---> Configuring Xaw3d Warning: reinplace s|-o root -g wheel|-o rschmidt -g staff| didn't change anything in /mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/xc/lib/Xaw3d/Makefile ---> Building Xaw3d ---> Staging Xaw3d into destroot ---> Deactivating Xaw3d @1.5E_1 ---> Installing Xaw3d @1.5E_2 ---> Activating Xaw3d @1.5E_2 ---> Cleaning Xaw3d ---> Uninstalling Xaw3d @1.5E_1
I originally added this reinplace in r40222 and Marcus updated it in r41534.
Attachments (1)
Change History (16)
comment:1 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jeremyhu@… added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
I spoke too soon.
On one of my systems (MacBook Pro, 10.4.11, Xcode 2.5, MacPorts 1.7.0) I see this when configuring Xaw3d:
DEBUG: Searching for dependency: imake DEBUG: Didn't find receipt, going to depspec regex for: imake DEBUG: Found Dependency: path: /usr/X11R6/bin filename: xmkmf regex: ^xmkmf$ DEBUG: Executing org.macports.main (Xaw3d) DEBUG: Skipping completed org.macports.fetch (Xaw3d) DEBUG: Skipping completed org.macports.checksum (Xaw3d) DEBUG: Skipping completed org.macports.extract (Xaw3d) DEBUG: Executing org.macports.patch (Xaw3d) ---> Configuring Xaw3d DEBUG: Using compiler 'Mac OS X gcc 4.0' DEBUG: Executing org.macports.configure (Xaw3d) DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.4' DEBUG: Assembled command: 'cd "/mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/xc/lib/Xaw3d" && xmkmf' imake -DUseInstalled -I/usr/X11R6/lib/X11/config make: Nothing to be done for `Makefiles'.
imake was found in ${x11prefix} and it gets called with "-I${x11prefix}/lib/X11/config" and puts root/wheel into the Makefile:
$ grep "wheel" -r $(port dir Xaw3d)/work/xc/ /Users/rschmidt/macports/dports/x11/Xaw3d/work/xc/lib/Xaw3d/Makefile: INSTALLFLAGS = -c -o root -g wheel grep: warning: /Users/rschmidt/macports/dports/x11/Xaw3d/work/xc/lib/Xaw3d/X11/Xaw3d: recursive directory loop
This must be the system on which I originally added the reinplace to remove root/wheel, because if I don't, then I don't have permission to install it because this MacPorts installation runs under my user, not root.
$ port install gv ---> Fetching Xaw3d ---> Verifying checksum(s) for Xaw3d ---> Extracting Xaw3d ---> Configuring Xaw3d ---> Building Xaw3d ---> Staging Xaw3d into destroot Error: Target org.macports.destroot returned: shell command " cd "/mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/xc/lib/Xaw3d" && make install DESTDIR=/mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/destroot INCDIR=/mp/include SHLIBDIR=/mp/lib USRLIBDIR=/mp/lib " returned error 2 Command output: install -c -o root -g wheel -m 0644 libXaw3d.7.0.dylib /mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/destroot/mp/lib install: /mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/destroot/mp/lib/libXaw3d.7.0.dylib: chown/chgrp: Operation not permitted make: *** [install] Error 71
If I install the imake port first, then I get:
DEBUG: Searching for dependency: imake DEBUG: Found Dependency: receipt exists for imake DEBUG: Executing org.macports.main (Xaw3d) DEBUG: Skipping completed org.macports.fetch (Xaw3d) DEBUG: Skipping completed org.macports.checksum (Xaw3d) DEBUG: Skipping completed org.macports.extract (Xaw3d) DEBUG: Executing org.macports.patch (Xaw3d) ---> Configuring Xaw3d DEBUG: Using compiler 'Mac OS X gcc 4.0' DEBUG: Executing org.macports.configure (Xaw3d) DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.4' DEBUG: Assembled command: 'cd "/mp/var/macports/build/_Users_rschmidt_macports_dports_x11_Xaw3d/work/xc/lib/Xaw3d" && xmkmf' imake -DUseInstalled -I/mp/lib/X11/config make: Nothing to be done for `Makefiles'.
Now it finds imake in ${prefix}, calls imake with "-I${prefix}/lib/X11/config" and the Makefile doesn't contain a reference to root/wheel anymore, which is what I want:
$ grep "wheel" -r $(port dir Xaw3d)/work/xc/ grep: warning: /Users/rschmidt/macports/dports/x11/Xaw3d/work/xc/lib/Xaw3d/X11/Xaw3d: recursive directory loop
So should all imake-using ports be changed to bring in imake via a port-style dependency instead (possibly except when using +system_x11 on Tiger)?
comment:3 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Ugg... I'd rather all imake-using ports be punted, but yes, I suppose that is a good option. We'd need to edit macports base to have use_xmkmf add port:imake instead of bin:xmkmf:imake and make sure depends_build contains port:imake on all those ports until this updated use_xmkmf gets into a final 1.8.0 release...
=/
comment:4 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Note that MacPorts base was only updated to use bin:xmkmf:imake in the first place in r43783; that change is only in trunk and hasn't been in a released version of MacPorts yet.
comment:5 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
These ports declare dependencies on imake:
- Xaw3d
- canna
- emiclock
- fvwm
- glut
- kinput2
- kinput2-macim
- kxterm
- magicpoint
- spim
- sunclock
- tgif
- tightvnc
- transfig
- vtwm
- wmclock
- xcb
- xearth
- xfig
- xsnow
- xspringies
- xtu
comment:6 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | fenner@… mdales@… pguyot@… qbarnes@… takanori@… added |
---|---|
Port: | canna emiclock fvwm glut kinput2 kinput2-macim kxterm magicpoint spim sunclock tgif tightvnc transfig vtwm wmclock xcb xearth xfig xsnow xspringies xtu added |
Summary: | Xaw3d: reinplace didn't change anything → imake-using ports use wrong X11 libraries when using system xmkmf instead of imake port |
The following ports do not need to be fixed: glut (became a stub port in r47381)
I have fixed the following openmaintainer and nomaintainer ports: spim (r47624); canna emiclock fvwm kinput2 kinput2-macim kxterm sunclock tightvnc transfig wmclock Xaw3d xearth xfig xsnow xspringies xtu (r48826)
The following ports still need to be fixed and are not openmaintainer: magicpoint tgif vtwm xcb. I'm attaching a patch for these. The maintainers of these ports should speak up if they do not want these changes committed for some reason. Otherwise if I don't hear from the maintainers I will commit them after the 72-hour timeout.
Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | imake.diff added |
---|
patches for magicpoint tgif vtwm xcb
comment:7 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Fixed the use_xmkmf
function in MacPorts base in r48830.
comment:8 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
In r48738, I added a system_x11 variant to imake.
With system_x11, imake might not install ${prefix}/bin/imake.
Would port:imake therefore be a better dependency than path:bin/xmkmf:imake?
comment:9 follow-up: 10 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
I've been trying to get in the habit of using path:-style dependencies in general. The way it works is that the dependency is satisfied if either the indicated path exists or the indicated port is installed. I don't care strongly one way or another which style is used in this specific case, but if your concern is that the path:-style will not work with the +system_x11 variant, then I don't think you need to worry about that; I think it will work correctly.
comment:10 Changed 16 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Replying to ryandesign@…:
I've been trying to get in the habit of using path:-style dependencies in general. The way it works is that the dependency is satisfied if either the indicated path exists or the indicated port is installed. I don't care strongly one way or another which style is used in this specific case, but if your concern is that the path:-style will not work with the +system_x11 variant, then I don't think you need to worry about that; I think it will work correctly.
I did not fully understand how path:-stye dependencies worked.
Thank you for the clarification.
comment:13 Changed 15 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I can't figure out why this is no longer necessary, but I'm removing it in r45945.