legacy-support @1.1.1_0: fails to build on 10.4.11

[lazd (Larry Davis)]

I get the following error when trying to install legacy-support:

:info:build Undefined symbols:
:info:build   "___mpls_libc_opendir", referenced from:
:info:build       ___mpls_opendir in fdopendir.dl.o
:info:build       _fdopendir in fdopendir.dl.o
:info:build   "___mpls_libc_rewinddir", referenced from:
:info:build       ___mpls_rewinddir in fdopendir.dl.o
:info:build   "___mpls_libc_telldir", referenced from:
:info:build       ___mpls_telldir in fdopendir.dl.o
:info:build   "___mpls_libc_seekdir", referenced from:
:info:build       ___mpls_seekdir in fdopendir.dl.o
:info:build   "___mpls_libc_readdir", referenced from:
:info:build       ___mpls_readdir in fdopendir.dl.o
:info:build   "___mpls_libc_readdir_r", referenced from:
:info:build       ___mpls_readdir_r in fdopendir.dl.o
:info:build   "___mpls_libc_closedir", referenced from:
:info:build       ___mpls_closedir in fdopendir.dl.o
:info:build       ___mpls_opendir in fdopendir.dl.o
:info:build       _fdopendir in fdopendir.dl.o
:info:build ld: symbol(s) not found
:info:build collect2: ld returned 1 exit status
:info:build make: *** [lib/libMacportsLegacySupport.dylib] Error 1

See attachment main.log for full log output.

System info

• Mac OS X 10.4.11 (darwin/8.11.0) arch powerpc
• MacPorts 2.8.1
• Xcode 2.5, CLT none

[lazd (Larry Davis)]

Logfile from install

[macportsraf]

Thanks for the report.

I thought that this had been tested on 10.4, but maybe the very latest version wasn't re-tested.

These are all of the wrapper functions declared using __DARWIN_ALIAS, __DARWIN_ALIAS_I or __DARWIN_INODE64 (or __MPLS_* renamed versions of these macros) (but not fdopendir itself - interesting).

The macros used need to match whatever is used in the system dirent.h. My guess is that those function names are declared in 10.4's system dirent.h using different __DARWIN_* macros, and they need to be changed on 10.4 to match. But that's just a guess. I hope that's the problem, because it should be easy to fix (and it was half-expected).

If I need to change legacysupport's dirent.h for 10.4, what's the best way to identify the current platform in dirent.h? Is there a macro I can refer to? And what value corresponds to 10.4?

Can someone send me the 10.4 system dirent.h file? That might tell me what I need to change (if this is the problem).

I've dug out my battered 10.4 PowerBook G4, and its mangled power cord seems to be working. It's booting now! Probably for the first time in 13 years!

I'll check its dirent.h and I might even be able to install macports and legacysupport on it!

Err, it can't join my wifi network. Hmm, enabling old WPA doesn't help. Oh dear, it only works unencrypted! I might need some ethernet.

But I should be able to find dirent.h. I'll keep you posted. But send 10.4's dirent.h if you can. Thanks.

Actually, I can't get to ​http://www.macports.org to install macports. It redirects to https and it doesn't support 19-year-old SSL. It looks like I won't be able to install macports on it! No!!!

[lazd (Larry Davis)]

Mac OS 10.4 dirent.h

[lazd (Larry Davis)]

Replying to macportsraf:

But send 10.4's dirent.h if you can. Thanks.

Thanks for digging into this! I've attached MacOSX10.4u.sdk's dirent.h as found on my 10.4.11 machine, hopefully that helps.

The macros used need to match whatever is used in the system dirent.h

It does seem they use __DARWIN_ALIAS macros in 10.4's dirent.h...

As far as getting your old G4 online, you're on the right track. Open network, and use InterwebPPC ​https://github.com/wicknix/InterWebPPC to get around the SSL issues. Alternatively, enable file sharing, download the Tiger installer from ​https://github.com/macports/macports-base/releases/download/v2.8.1/MacPorts-2.8.1-10.4-Tiger.dmg, and drop into the Drop Box folder on your G4.

[macportsraf]

I don't think that's the problem.

On 10.4, dirent.h has:

DIR *opendir(const char *) __DARWIN_ALIAS(opendir);

int closedir(DIR *) __DARWIN_ALIAS(closedir);

struct dirent *readdir(DIR *);

int readdir_r(DIR *, struct dirent *, struct dirent **);

void rewinddir(DIR *) __DARWIN_ALIAS(rewinddir);

void seekdir(DIR *, long) __DARWIN_ALIAS(seekdir);

long telldir(DIR *) __DARWIN_ALIAS(telldir);

The current implementation of LegacySupport has:

DIR *__mpls_libc_opendir(const char *name) __MPLS_ALIAS_I(opendir);

int __mpls_libc_closedir(DIR *dir) __MPLS_ALIAS(closedir);

struct dirent *__mpls_libc_readdir(DIR *dir) __MPLS_INODE64(readdir);

int __mpls_libc_readdir_r(DIR *dir, struct dirent *entry, struct dirent **result) __MPLS_INODE64(readdir_r);

void __mpls_libc_rewinddir(DIR *dir) __MPLS_ALIAS_I(rewinddir);

void __mpls_libc_seekdir(DIR *dir, long loc) __MPLS_ALIAS_I(seekdir);

long __mpls_libc_telldir(DIR *dir) __MPLS_ALIAS_I(telldir);

Which translates to:

DIR *__mpls_libc_opendir(const char *name) __DARWIN_ALIAS(opendir);

int __mpls_libc_closedir(DIR *dir) __DARWIN_ALIAS(closedir);

struct dirent *__mpls_libc_readdir(DIR *dir) __DARWIN_ALIAS(readdir);

int __mpls_libc_readdir_r(DIR *dir, struct dirent *entry, struct dirent **result) __DARWIN_ALIAS(readdir_r);

void __mpls_libc_rewinddir(DIR *dir) __DARWIN_ALIAS(rewinddir);

void __mpls_libc_seekdir(DIR *dir, long loc) __DARWIN_ALIAS(seekdir);

long __mpls_libc_telldir(DIR *dir) __DARWIN_ALIAS(telldir);

If my hypothesis had been correct, that should mean that readdir and readdir_r should fail to be found (because __MPLS_INODE64 was incorrectly defaulting to __DARWIN_ALIAS (rather than nothing) when __DARWIN_INODE64 wasn't defined), but the other functions should have been found.

I've made the appropriate fix for __DARWIN_INODE64 in an unrelated pull request, but I don't think it'll help here because of the other link failures.

Thanks for the dirent.h and thanks for the advice on getting macports onto my lovely old PowerBook. Maybe I can do some local testing and make sense of this problem (but I am mystified).

If anyone else has any ideas about what might be the cause, please let me know.

[macportsraf]

I'm now seeing the same problem on 10.4. I can't successfully install apple-gcc42 because of this legacy-support failure. And I can't compile a local copy of legacysupport because there's no system copyfile.h file.

And I think this is a big problem. Even if the __asm renaming worked to rename the __mpls_libc_* functions to their underlying system functions, it was all assuming that all of these functions used one of the aliasing macros (__DARWIN_ALIAS, __DARWIN_ALIAS_I, __DARWIN_INODE64), but on 10.4 two of the functions don't use an aliasing macro.

So even if things were working as I expected them to, the readdir and readdir_r functions wouldn't be able to work.

But the __asm renaming isn't working as I expected it to so there's more to it.

We might need to revert to a macro-based implementation rather than an __asm renaming-based implementation.

I'll bring this up at ​https://github.com/macports/macports-legacy-support/pull/62

[kencu (Ken)]

apple-gcc42 really cannot / should not depend on legacy-support.

apple-gcc42 always previously built with only system roots, first in +bootstrap mode, and then in -bootstrap mode, and it would be very unfortunate if that has changed as the system gcc compiler on Tiger is very old and incapable, and really can only be expected to build apple-gcc42, which is far more capable.

[macportsraf]

Thanks. My mistake. I was really installing openssh at the time. It must have been that or one of its other dependencies that depended on legacy-support. I do have the bootstrap variant of apple-gcc42 installed. I'm install the non-bootstrap variant now.

I'm able to test legacysupport locally on 10.4. I'm reproducing this error, and I have suggested a fix (abandon asm renaming and go back to using macros for all the wrapper functions). I'll be able to tell if that works or not. I'm fairly sure it will, because an earlier version did that and was tested on 10.4 by someone.

[macportsraf]

It's fixed in this pull request: ​https://github.com/macports/macports-legacy-support/pull/69

That needs to fix a separate issue as well. Hopefully it does, and will get merged soon.

Thanks again for the bug report, and thanks for giving me motivation to set up my 10.4 laptop for macports testing.

However, I noticed a problem with setreuid/setregid on 10.4, which is needed by the LegacySupport implementation of faccessat. They return 0 but they aren't correct. They set the effective uid/gid but not the real uid/gid. This doesn't affect the automatic make test tests, because they aren't run setuid/setgid. But if someone manually runs sudo make test_faccessat_setuid, those tests would fail. Since the faccessat implementation has only just started working at all on other platforms, this probably isn't important, but I thought I should mention it. Maybe setreuid and setregid should/could be fixed as well (separately to this). Or maybe the local system implementation on 10.4 should be accepted for what it is?

[lazd (Larry Davis)]

Replying to macportsraf:

It's fixed in this pull request: ​https://github.com/macports/macports-legacy-support/pull/69

That needs to fix a separate issue as well. Hopefully it does, and will get merged soon.

Thanks again for the bug report, and thanks for giving me motivation to set up my 10.4 laptop for macports testing.

Nice work! I'm happy to test locally on a 10.4.11 VM if there are docs on how to do so.

Glad to report the bug, and happy it encouraged you to get your old Tiger laptop out for testing! You can also test using UTM ​https://getutm.app/ (qemu under the hood) on any macOS machine, it's easy to get a Tiger VM up and running and it's quite fast. There are a set of configs here ​https://github.com/adespoton/utmconfigs that can help get you up and running for 10.4 on a PPC.

[kencu (Ken)]

the best Tiger VM I have used runs on VirtualBox, instructions here:

​https://github.com/ranma42/TigerOnVBox

Intel only though.

I tried a PPC VM using qemu but ultra slow so mothballed it.

Edit: on my M1 MacBookPro, qemu PPC works much faster than on my last attempt with an Intel system. It's arguably usably fast now... the only thing so far is I can't get any sound out of the VM, but that's not a major hiccup.

[kencu (Ken)]

Just a note that both legacy-support @1.1.1_0 and legacy-support-devel @20230915_0 remain broken on Tiger and are uninstallable at present due to this issue:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_legacy-support/legacy-support-devel/work/compwrap/cc/opt/local/bin/gcc-apple-4.2 -arch ppc -dynamiclib -headerpad_max_install_names -install_name @executable_path/../lib/libMacportsLegacySupport.dylib -current_version 1.1.99 -compatibility_version 1.0.0 -L/opt/local/lib -Wl,-headerpad_max_install_names src/arc4random.dl.o src/atcalls.dl.o src/best_fchdir.dl.o src/dprintf.dl.o src/fdopendir.dl.o src/fmemopen.dl.o src/fsetattrlist.dl.o src/fsgetpath.dl.o src/getdelim.dl.o src/getentropy.dl.o src/getline.dl.o src/lchmod.dl.o src/lutimes.dl.o src/macports_legacy_copyfile.dl.o src/macports_legacy_os_unfair_lock.dl.o src/macports_legacy_realpath.dl.o src/macports_legacy_sysconf.dl.o src/memmem.dl.o src/memstream.dl.o src/posix_memalign_emulation.dl.o src/pthread_setname_np.dl.o src/setattrlistat.dl.o src/sincos.dl.o src/strings.dl.o src/strndup.dl.o src/strnlen.dl.o src/time.dl.o src/utimensat.dl.o src/wcpcpy_family.dl.o src/wcscasecmp_family.dl.o src/wcsdup.dl.o src/wcsnlen.dl.o -o lib/libMacportsLegacySupport.dylib
:info:build Undefined symbols:
:info:build   "___mpls_libc_opendir", referenced from:
:info:build       ___mpls_opendir in fdopendir.dl.o
:info:build       _fdopendir in fdopendir.dl.o
:info:build   "___mpls_libc_rewinddir", referenced from:
:info:build       ___mpls_rewinddir in fdopendir.dl.o
:info:build   "___mpls_libc_telldir", referenced from:
:info:build       ___mpls_telldir in fdopendir.dl.o
:info:build   "___mpls_libc_seekdir", referenced from:
:info:build       ___mpls_seekdir in fdopendir.dl.o
:info:build   "___mpls_libc_readdir", referenced from:
:info:build       ___mpls_readdir in fdopendir.dl.o
:info:build   "___mpls_libc_readdir_r", referenced from:
:info:build       ___mpls_readdir_r in fdopendir.dl.o
:info:build   "___mpls_libc_closedir", referenced from:
:info:build       ___mpls_closedir in fdopendir.dl.o
:info:build       ___mpls_opendir in fdopendir.dl.o
:info:build       _fdopendir in fdopendir.dl.o

This renders Tiger non-functional for some months now, unless users override the current legacy-support version manually with an overlay repo.

The last legacy-support I have installed is legacy-support @1.0.10_0 so users can try to peg back to that version until this is sorted out.

[macportsraf]

Sorry for the delay with ​https://github.com/macports/macports-legacy-support/pull/69. We ended up with a much much simpler fix that also fixes ​https://trac.macports.org/ticket/68253 but we're waiting for it to be tested.

If it's super urgent, I could do a separate fix for 10.4 only, and then change the above pull request to undo that change, but I'm really hoping to avoid that. It would make that pull request take even longer to test. Really, it would have to wait until after a 10.4-only fix was merged.

I'll ask over at ​https://trac.macports.org/ticket/68253 if anyone can test it.

[fhgwright (Fred Wright)]

I just submitted ​https://github.com/macports/macports-ports/pull/21775, which doesn't fix this problem as described, but does roll back the port to 1.0.13 on 10.4, which fixes the immediate problem. There has yet to be a newer version that works on 10.4, in spite of claims to the contrary.

[fhgwright (Fred Wright)]

In 4dfed8c96d320cc56046be72392b8a0206344aa9/macports-ports (master):

legacy-support: update to v1.2.1

Also removes the now-unnecessary version holdback for OS 10.4.

Retains the -devel subport, since it's likely to be needed again in
the not-too-distant future. At this time, the -devel and non-devel
versions are identical, but the -devel version is still referenced to
the commit ID rather than the version, for easier future editing.

Closes: #68314

TESTED:
Tested both normal and -devel versions (currently identical) on
10.4-10.5 ppc, 10.5-10.6 ppc (x86_64 Rosetta), 10.4-10.6 i386,
10.4-12.x x86_64, and 11.x-14.x arm64.
Builds on all tested platforms except 10.5 ppc +universal.
Passes all -universal tests.
Buildable +universal cases pass all tests, except for expected
failures on 10.11-10.13 x86_64 +universal (i386).