muniversal PG failure combined with github PG

[RJVB (René Bertin)]

The muniversal PG makes a copy of the patched worksrcpath in its configure block. That's a good idea but not appropriate if worksrcpath is a symlink (as likely when using the github PG) and build.dir==worksrcpath.

In that case only the 1st architecture gets build, as I discovered after upgrading port:legacy-support+universal (I got a universal dylib containing only the i386 binary).

The proper thing to do would be something like

diff --git a/_resources/port1.0/group/muniversal-1.0.tcl b/_resources/port1.0/group/muniversal-1.0.tcl
index d3d886b03c8d5ab3347047cc325c96b23dbcc57a..039f0b1668e0f3f7bb9cbcd8dc5c9b0422dc0683 100644
--- a/_resources/port1.0/group/muniversal-1.0.tcl
+++ b/_resources/port1.0/group/muniversal-1.0.tcl
@@ -186,7 +186,21 @@ variant universal {
             set muniversal.current_arch ${arch}
 
             if {![file exists ${worksrcpath}-${arch}]} {
-                copy ${worksrcpath} ${worksrcpath}-${arch}
+                if {[file type ${worksrcpath}] eq "link" && ${build.dir} eq "${worksrcpath}"} {
+                    set target [file link ${worksrcpath}]
+                    if {![file exists ${target}]} {
+                        set fulltarget [file join [file dirname ${worksrcpath}] ${target}]
+                        if {![file exists ${fulltarget}]} {
+                            ui_error "${worksrcpath} is a link not pointing to an absolute directory or to a directory in the same parent directory"
+                            return -code error "unsupported worksrcpath link target"
+                        } else {
+                            set target ${fulltarget}
+                        }
+                    }
+                    copy ${target} ${worksrcpath}-${arch}
+                } else {
+                    copy ${worksrcpath} ${worksrcpath}-${arch}
+                }
             }
 
             set archf [muniversal_get_arch_flag ${arch}]

[kencu (Ken)]

Hmmm -- it works just fine for me:

$ port -v installed | grep legacy
  legacy-support @0.12_0+universal (active) platform='darwin 10' archs='i386 x86_64' date='2020-05-10T09:10:41-0700'

and

$ file /opt/local/lib/libMacportsLegacySupport.dylib
/opt/local/lib/libMacportsLegacySupport.dylib: Mach-O universal binary with 2 architectures
/opt/local/lib/libMacportsLegacySupport.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/lib/libMacportsLegacySupport.dylib (for architecture i386):	Mach-O dynamically linked shared library i386

[kencu (Ken)]

Could this have anything to do with some modifications you may have made on your system? I will check my 10.9 VM and see what it shows there.

[kencu (Ken)]

Nope, 10.9 is fine too:

$ port -v installed | grep legacy
  legacy-support @0.12_0+universal (active) platform='darwin 13' archs='i386 x86_64' date='2020-05-17T10:01:29-0700'

$ file /opt/local/lib/libMacportsLegacySupport.dylib
/opt/local/lib/libMacportsLegacySupport.dylib: Mach-O universal binary with 2 architectures
/opt/local/lib/libMacportsLegacySupport.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
/opt/local/lib/libMacportsLegacySupport.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64

[RJVB (René Bertin)]

Replying to kencu:

Could this have anything to do with some modifications you may have made on your system? I will check my 10.9 VM and see what it shows there.

Not impossible; it surprised me that this wouldn't have been caught before. But I don't see which and my analysis seems sound.

What do you see when you do

ls -l `port work legacy-support`

I see

> ll `port work legacy-support`
total 8
17761567 0 drwxr-xr-x 12 bertin admin 476 May 17 17:27 ./
17761566 0 drwxr-xr-x  3 bertin admin 136 May 17 17:19 ../
17761568 0 drwxr-xr-x  2 bertin admin  68 May 17 17:19 .home/
17761570 4 -rw-r--r--  1 bertin admin 321 May 17 17:27 .macports.legacy-support.state
17761569 0 drwxr-xr-x  2 bertin admin  68 May 17 17:19 .tmp/
17762546 0 drwxr-xr-x  3 bertin admin 102 May 17 17:28 destroot/
17762056 0 drwxr-xr-x  7 bertin admin 238 May 17 17:27 destroot-i386/
17762383 0 drwxr-xr-x  7 bertin admin 238 May 17 17:27 destroot-intel/
17762382 0 drwxr-xr-x  2 bertin admin  68 May 17 17:27 destroot-powerpc/
17762219 0 drwxr-xr-x  7 bertin admin 238 May 17 17:27 destroot-x86_64/
17761646 4 lrwxr-xr-x  1 bertin admin  40 May 17 17:19 macports-legacy-support-0.12 -> macports-macports-legacy-support-f75ea79/
17761648 0 drwxr-xr-x  8 bertin admin 442 May 17 17:27 macports-legacy-support-0.12-i386/
17761723 0 drwxr-xr-x  8 bertin admin 442 May 17 17:27 macports-legacy-support-0.12-x86_64/
17761572 0 drwxr-xr-x  7 bertin admin 408 May 17 17:19 macports-macports-legacy-support-f75ea79/

with my patch. Without, the arch-specific source dir copies (and build dirs) are symlinks too, and invoking make in them will evidently just give a message that nothing needs to be done. Or, alternatively, it would overwrite the existing build products.

FWIW, initially I did think this was my own doing because I vaguely recalled having tried to use symlinks in the muniversal PG, which could save a lot of disk space - but I clearly abandoned that change. Currently my muniversal PG only has a few unrelated tweaks and I use the stock github PG.

[kencu (Ken)]

here's what I have on 10.7:

$ ls -la
total 256
drwxr-xr-x  15 macports  admin     510 17 May 13:32 .
drwxr-xr-x   3 macports  admin     102 17 May 13:31 ..
-rw-r--r--   1 macports  admin  122641 17 May 13:31 .CC_PRINT_OPTIONS
drwxr-xr-x   2 macports  admin      68 17 May 13:31 .home
-rw-r--r--   1 macports  admin     307 17 May 13:32 .macports.legacy-support.state
drwxr-xr-x   2 macports  admin      68 17 May 13:31 .tmp
drwxr-xr-x   3 root      admin     102 17 May 13:32 destroot
drwxr-xr-x   7 root      admin     238 17 May 13:31 destroot-i386
drwxr-xr-x   7 root      admin     238 17 May 13:32 destroot-intel
drwxr-xr-x   2 root      admin      68 17 May 13:32 destroot-powerpc
drwxr-xr-x   7 root      admin     238 17 May 13:31 destroot-x86_64
lrwxr-xr-x   1 macports  admin      40 17 May 13:31 macports-legacy-support-0.12 -> macports-macports-legacy-support-f75ea79
drwxr-xr-x  12 macports  admin     408 17 May 13:31 macports-legacy-support-0.12-i386
drwxr-xr-x  12 macports  admin     408 17 May 13:31 macports-legacy-support-0.12-x86_64
drwxr-xr-x  11 macports  admin     374  9 May 14:40 macports-macports-legacy-support-f75ea79

and all looks fine there too:

$ file destroot/opt/local/lib/libMacportsLegacySupport.dylib
destroot/opt/local/lib/libMacportsLegacySupport.dylib: Mach-O universal binary with 2 architectures
destroot/opt/local/lib/libMacportsLegacySupport.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
destroot/opt/local/lib/libMacportsLegacySupport.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64

looks like this has to be something unique to your setup somehow. There are many ports that use both github and muniversal, I think -- nobody ever had an issue before, AFAIK...

[RJVB (René Bertin)]

Has there ever been experimentation with the builtin copy command, making it copy symlinks instead of copying the target of the symlink (like Tcl's file copy command does)? I run "base" from the master branch, fwiw.

[kencu (Ken)]

would you have 5 minutes to do a quick install to another macports prefix on your machine and just see if this happens on a stock, unmodified macports on your machine? legacy-support has no deps, so there would be nothing else to install to test it, other than the bare-bones macports.

I just can't reproduce it, and I suspect that somehow, it must have something to do with some mod you might have made -- what/where/when/how/why I don't know.

[RJVB (René Bertin)]

Knowing me I will be spending more than 5 minutes on this ;) but I should be able to find some time to do that.

But I just checked: the copy command in portutil just proxies the Tcl file copy command, and per the documentation that function is supposed to copy symlinks.

I could still imagine some subtle effect from my set-up (rather than my mods; my /opt/local is a symlink but my /opt/local/var/macports/build is one too; both volumes are case-sensitive) but in the end I am just as incapable to explain why things work for you as you're incapable to reproduce the issue.

Or do you see anything in the relevant documentation that suggests that copy should indeed be duplicating the target directory here instead of just creating a duplicate link? EDIT: quote: When copying within a single filesystem, \fIfile copy\fR will copy soft links (i.e. the links themselves are copied, not the things they point to). We should always be in that situation, as MacPorts creates the work directory itself, when needed.

[RJVB (René Bertin)]

OK, I understand now. This was not so much caused by one of my mods, but by the fact that I messed up during a recent refactor, missing commit #b9564a04 . Which has the same intent and justification as my patch. I'm not certain why I didn't catch that while double-checking things - I did before creating this ticket.

At least we were both right :)

[kencu (Ken)]

ok, thanks for confirming.