legacy-support-devel @20211111: "port" wedged after deactivation

[evanmiller (Evan Miller)]

This is a strange one. I have three parallel MacPorts installations. After deactivating legacy-support-devel on one of them (with the intention of activating legacy-support), none of the port binaries are usable:

$ port
dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6): symbol not found
    while executing
"load /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib"
    ("package ifneeded Pextlib 1.0" script)
    invoked from within
"package require Pextlib 1.0"
    (file "/opt/local/libexec/macports/lib/registry2.0/receipt_flat.tcl" line 37)
    invoked from within
"source /opt/local/libexec/macports/lib/registry2.0/receipt_flat.tcl"
    ("package ifneeded receipt_flat 1.0" script)
    invoked from within
"package require receipt_flat 1.0"
    (file "/opt/local/libexec/macports/lib/registry2.0/registry.tcl" line 36)
    invoked from within
"source /opt/local/libexec/macports/lib/registry2.0/registry.tcl"
    ("package ifneeded registry 1.0" script)
    invoked from within
"package require registry 1.0"
    (file "/opt/local/libexec/macports/lib/registry2.0/portuninstall.tcl" line 35)
    invoked from within
"source /opt/local/libexec/macports/lib/registry2.0/portuninstall.tcl"
    ("package ifneeded registry_uninstall 2.0" script)
    invoked from within
"package require registry_uninstall 2.0"
    (file "/opt/local/libexec/macports/lib/macports1.0/reclaim.tcl" line 52)
    invoked from within
"source /opt/local/libexec/macports/lib/macports1.0/reclaim.tcl"
    ("package ifneeded reclaim 1.0" script)
    invoked from within
"package require reclaim 1.0"
    (file "/opt/local/libexec/macports/lib/macports1.0/diagnose.tcl" line 68)
    invoked from within
"source /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl"
    ("package ifneeded diagnose 1.0" script)
    invoked from within
"package require diagnose 1.0"
    (file "/opt/local/libexec/macports/lib/macports1.0/macports.tcl" line 38)
    invoked from within
"source /opt/local/libexec/macports/lib/macports1.0/macports.tcl"
    ("package ifneeded macports 1.0" script)
    invoked from within
"package require macports"
    (file "/opt/local/bin/port" line 46)

(Similar error when invoking the other port binaries in separate installation directories, which is the strangest part.)

Any ideas on what's going on and how I can un-wedge the system with reinstalling MacPorts? Restarted to no avail. 10.4.11/PPC

[kencu (Ken)]

what does otool say this is linked to?

/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib

[evanmiller (Evan Miller)]

/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib:
    /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libcurl.4.dylib (compatibility version 12.0.0, current version 12.0.0)
    @loader_path/../registry2.0/registry.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /opt/local/lib/libgcc/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

[evanmiller (Evan Miller)]

Will have to research later but the only thing I think these installations have in common is libcurl (since they all used the curl bootstrap process).

[kencu (Ken)]

I assume you are rebuilding macports using --with-curlprefix=/opt/local.

I anticipated this might someday break in this fashion, so I use a stock MacPorts in /opt/bootstrap as the curl donor, linked against only system roots, and then built macports in /opt/local against that.

If a curl update in /opt/bootstrap breaks the port in /opt/local, I would just rebuild macports in /opt/local from source against /opt/bootstrap. But it never broke, as macports base updates were frequent enough to keep up with curl changes naturally I guess.

In your case here, you could probably just rebuild macports from source against the curl in /opt/local and lay it on top of what is in /opt/local now, and it should fix you up.

Then if that does work, do the same with your other macports installs.

But consider keeping one stock, for a failsafe, perhaps.

[kencu (Ken)]

is there anything in the curl dependency chain that now depends on legacysupport?

If so, then that might be why deactivating legacysupport brought you down...

And if so, things are getting much more fragile, and the stock /opt/bootstrap curl donor might be the only viable option (or some other newer curl install method)

[cjones051073 (Chris Jones)]

Yeah, for me building base linking it against macports own binaries that that port installation manages, is effectively a circular dependency and as such should be avoided. If you need to build base against a custom libcurl, or anything else, then I think you have to use a bootstrap installation as Ken mentions, to avoid this sort of issue. I am not sure there is much we can do on the port side to help here.

[evanmiller (Evan Miller)]

I guess this is really a duplicate of #51516 then

[cjones051073 (Chris Jones)]

Well, not a duplicate in the strict sense, but it is correct if that ticket was addressed what you did here would not have been necessary. Until then, the fix is the bootstrap approach outlined by Ken. Closing as there is not much else to be done on the port side.

[kencu (Ken)]

I wonder if it would be most efficient to find a way to use the /opt/local port installation to build a bare-bones curl that will install completely separately in /opt/curl or some such -- kind of the way we build libc++ with macports in /opt/local, but thereafter it is installed and untouched by macports in /usr/lib, even if libcxx is deactivated or installed.

Then at least a whole pile of waste (compilers, port trees, useless installs of perl and python, etc) could all be avoided.

And macports would not "ship" a bundled curl, which seems to get people concerned.

Might just be a bit of work with copying some stuff and install_name_tool, if we were really lucky, kinda like what I did stealing libc++ from clang-11 to make the macports-libcxx port.

[evanmiller (Evan Miller)]

After going through /opt/bootstrap on a Snow Leopard install, it is more of a pain than I realized, with some still-unresolved circular compiler dependencies popping up along the way.

Based on that experience I would vote for including all needed curl sources and linking statically unless --with-curlprefix is supplied.

In any event we should continue discussion over in the other ticket.

[kencu (Ken)]

I just re- /opt/bootstrapped snowleopard again today as well.

I changed the cxxstdlib to libstdc++ to save 1000 deps.

everything then went smoothly, except glib2 doesn't build with /usr/bin/llvm-gcc-4.2 as is any more -- had to disable the tests, and then it built.

[evanmiller (Evan Miller)]

I started with Xcode 3.2.6 – perhaps that introduced additional complexity compared to using a newer version.

[cjones051073 (Chris Jones)]

Replying to kencu:

I wonder if it would be most efficient to find a way to use the /opt/local port installation to build a bare-bones curl that will install completely separately in /opt/curl or some such -- kind of the way we build libc++ with macports in /opt/local, but thereafter it is installed and untouched by macports in /usr/lib, even if libcxx is deactivated or installed.

Then at least a whole pile of waste (compilers, port trees, useless installs of perl and python, etc) could all be avoided.

And macports would not "ship" a bundled curl, which seems to get people concerned.

Might just be a bit of work with copying some stuff and install_name_tool, if we were really lucky, kinda like what I did stealing libc++ from clang-11 to make the macports-libcxx port.

I think that would get messy fast. you would have to copy quite a chain of dynamic libraries and fix them all up with install_name_tool. You would also have to copy over the headers for curl (at least) in order to build against that set of dylib, plus maybe who knows what else for the over deps.

personally I think it much easier to run the installation in a separate bootstrap area, and then just run 'sudo port reclaim' to remove all the build dependencies, etc., after the fact.