meson @0.53.2 produces on PPC Mac OS X 10.4.11, Tiger, faulty files with illegal loader switch '-Wl,-rpath,@loader_path/'

[ballapete (Peter "Pete" Dyballa)]

-rpath can be used on Leopard, Mac OS X 10.5, not on Tiger.

[ballapete (Peter "Pete" Dyballa)]

See ​https://github.com/mesonbuild/meson/issues/6744.

[kencu (Ken)]

This patch improves the situation:

--- ./mesonbuild/linkers.py.orig	2020-03-26 16:17:42.000000000 -0700
+++ ./mesonbuild/linkers.py	2020-03-26 16:21:54.000000000 -0700
@@ -617,7 +617,7 @@
                         is_shared_module: bool) -> T.List[str]:
         if is_shared_module:
             return []
-        install_name = ['@rpath/', prefix, shlib_name]
+        install_name = ['@loader_path/', prefix, shlib_name]
         if soversion is not None:
             install_name.append('.' + soversion)
         install_name.append('.dylib')
@@ -645,7 +645,7 @@
         for rp in all_paths:
             args.extend(self._apply_prefix('-rpath,' + rp))
 
-        return args
+        return []
 
 
 class GnuDynamicLinker(GnuLikeDynamicLinkerMixin, PosixDynamicLinkerMixin, DynamicLinker):

see full discussion here:

<​https://github.com/kencu/TigerPorts/commit/753b2fefe6f60bb8c85682edf6178349e1527084>

[kencu (Ken)]

And this patch helps a bit more. With this one, things are pretty much back to the state we had before:

--- mesonbuild/modules/gnome.py.orig	2020-03-29 17:43:40.000000000 -0700
+++ mesonbuild/modules/gnome.py	2020-03-29 17:47:25.000000000 -0700
@@ -289,8 +289,8 @@
         if isinstance(lib, build.SharedLibrary):
             libdir = os.path.join(state.environment.get_build_dir(), state.backend.get_target_dir(lib))
             link_command.append('-L' + libdir)
-            if include_rpath:
-                link_command.append('-Wl,-rpath,' + libdir)
+            #KEN if include_rpath:
+            #KEN    link_command.append('-Wl,-rpath,' + libdir)
             depends.append(lib)
             # Needed for the following binutils bug:
             # https://github.com/mesonbuild/meson/issues/1911
@@ -299,8 +299,8 @@
             for d in state.backend.determine_rpath_dirs(lib):
                 d = os.path.join(state.environment.get_build_dir(), d)
                 link_command.append('-L' + d)
-                if include_rpath:
-                    link_command.append('-Wl,-rpath,' + d)
+                #KEN if include_rpath:
+                #KEN    link_command.append('-Wl,-rpath,' + d)
         if gir_has_option(self.interpreter, '--extra-library') and use_gir_args:
             link_command.append('--extra-library=' + lib.name)
         else:
@@ -357,8 +357,8 @@
                             getattr(dep, 'is_libtool', False)):
                         lib_dir = os.path.dirname(lib)
                         external_ldflags.update(["-L%s" % lib_dir])
-                        if include_rpath:
-                            external_ldflags.update(['-Wl,-rpath {}'.format(lib_dir)])
+                        #KEN if include_rpath:
+                        #KEN    external_ldflags.update(['-Wl,-rpath {}'.format(lib_dir)])
                         libname = os.path.basename(lib)
                         if libname.startswith("lib"):
                             libname = libname[3:]

[kencu (Ken)]

The main issue still remaining is running build tools or tests in the build directory using libraries that have been built during the build process, if the libraries are not immediately next to the binaries trying to run them. In that case, @loader_path can't find them.

Installing the libraries in the build directory with the full pathname to the library might work. We can find the path to the build directory with env.get_build_dir() so we can get that far without too much trouble. And we can modify get_soname_args to return the install name as that pathname + '/' + prefix + shlib_name.

The part I'm missing is the bit of the path between the base build_dir path and the actual library target path relative to the build_dir.

[kencu (Ken)]

I wonder if we could add rpath support to Tiger by installing a newer dyld <​https://opensource.apple.com/source/dyld/dyld-95.3/> and telling ld64-97 it's OK to allow @rpaths on Tiger (that part is easy).

[ballapete (Peter "Pete" Dyballa)]

A few months after Tiger's fifteenth anniversary that would be great progress.

[ballapete (Peter "Pete" Dyballa)]

Recent meson @0.55.3 needs different patches to build a target. They are attached here. the backend ninjabackend.py needs at least one of the comment patches or the function to generate the target will fail because there is no rpath element to remove. The patches do not seem to be complete, because installation and also test fail because of one reason: image not found. The binaries built for installation obviously cannot find shared libraries in, I think, ${workpath}/${name} or ${worksrcpath}/${name}.

[ballapete (Peter "Pete" Dyballa)]

Set of patches to allow build on Tiger without using -Wl,-rpath

[kencu (Ken)]

thanks, will check

[ballapete (Peter "Pete" Dyballa)]

I forgot to mention one detail: I am trying to build and install atk. The build succeeds but test and installation fail because the newly built libatk or such cannot be found. I've also seen -rpath appear when building gtk2 – should be checked as well!

[kencu (Ken)]

yes, at-sp2-atk is currently broken on Tiger due to meson's use of rpath. I pegged it at 2.28.0 until meson is fixed (if ever).

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

Installing the libraries in the build directory with the full pathname to the library might work.

This works at least for the optional step meson test. I have not yet tried port upgrade <whatever>.

We can find the path to the build directory with env.get_build_dir() so we can get that far without too much trouble. And we can modify get_soname_args to return the install name as that pathname + '/' + prefix + shlib_name.

The part I'm missing is the bit of the path between the base build_dir path and the actual library target path relative to the build_dir.

I presume both statements express that you would get a path name of /opt/local/var/macports/build/_opt_local_var_..._<whatever>/work/build/lib<whatever>-1.0.0.dylib instead of the correct value /opt/local/var/macports/build/_opt_local_var_..._<whatever>/work/build/*<whatever>*/lib<whatever>-1.0.0.dylib (at least in case of <whatever> = atk which I am testing). Some port or project name is missing between .../build/ and /lib<whatever>....

[kencu (Ken)]

At present, on systems that support @rpath, meson uses @rpath during the build and test phase.

From the top of the build directory, the @rpath library references are constructed and embedded into the executables. The libraries are all named with the @rpath/dylibname.dylib syntax, no matter where they are in the build tree, usually.

Then later, at the install phase, all the @rpath references are stripped out, the libraries are installed with their final full static names, and any installed executables are rejigged to point to those final installed library names.

meson assumes darwin is a standard @rpath using system, which it is, on 10.5+, and so meson is written assuming darwin is using @rpath in many places.

I hacked meson to use @loaderpath instead of @rpath for the library names, and this works surprisingly well, except when the libraries in the build directory are not in the same folder as the executables in the build directory, in which case it fails as it doesn't know what subdirectory to look in.

Instead of @loaderpath, if I could make meson use the full library path name, even in the build directory, then it would all work. Some other systems, like Windows, do this with meson. But there are intricacies to it and you can't just Bogart meson to use the full library path name on darwin like it does on windows, as there are many places in meson that windows and darwin code paths diverge.

I often can fix these builds manually -- changing the library path names in the build directory, or symlinking or moving a library into a workable spot -- but I'm not about to write a bunch of spaghetti like that for meson ports in general, so I have not been uploading that crud to MacPorts.

It can be done -- making darwin not use @rpath, but use full path names like meson does with windows -- but meson is a moving target, and it would be a project to do it -- and unless upstream is interested in taking this on, it's kind of a lost cause. And upstream has almost NO darwin users, and certainly NONE that use legacy systems. So that is a long long long shot.

We could fork meson and make it not use @rpath -- I am not interested in that project. Life is too short for me to do that.

SO -- we hack a bit, hope for the best, peg the really tricky ones like at-sp2-atk.

I am wondering if a wrapper script for ld might be written that could make @rpath references work on Tiger. OR if the dyld from Leopard could be built and installed on Tiger as that one supports @rpath.

BUT unless we sort this out soon, Tiger is doomed, as meson, with all it's warts, seems to be taking up a prime place in the GNOME world.

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

Using an installed Meson port without my last patch set, I get -install_name @rpath/libatk-1.0.0.dylib – this cannot be correct.

[kencu (Ken)]

Replying to ballapete:

Replying to kencu:

Using an installed Meson port without my last patch set, I get -install_name @rpath/libatk-1.0.0.dylib – this cannot be correct.

If you mean that an unpatched meson tries to use @rpath and this fails on Tiger -- well, yes it does...

[kencu (Ken)]

I'm just noting that I didn't push my last meson Tiger patches into MacPorts <​https://github.com/kencu/TigerPorts/tree/master/devel/meson>.

I'll see about updating to meson 55, and then whether I might do that.

meson updates frequently, my Tiger patches more slowly, so i tend to peg it and update it occassionally, like we do with libuv.

perhaps i can sell that idea for the main meson port here too...

[kencu (Ken)]

Peter -- if you like, give this a try : <​https://github.com/macports/macports-ports/pull/8848>.

It works (so far) for me, mostly. Needs more testing. The gnome document scanner is not yet finding the documents right, so I had to disable the docs in at-spi2-core but the rest of the ports seem at least marginally happy.

No doubt errors will be found, but ... a step.

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

Peter -- if you like, give this a try : <​https://github.com/macports/macports-ports/pull/8848>.

I started working on it. Portfile would need another patch, one that lets MacPorts' gnutar untar the archive to restore the original dates. This would also help with this ERROR:

ValueError: ZIP does not support timestamps before 1980

Testing Meson needs some extra Python packages and possibly some other software ('gcovr'). Finding this will be more successful after some sleep…

[ballapete (Peter "Pete" Dyballa)]

I think Ninja also needs a fix. At least I presume *it* is producing these reports:

WARNING: 'nm' does not work. Relinking will always happen on source changes.
error: nm: invalid argument --
Usage: nm [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch <arch_flag>] ...] [file ...]

[kencu (Ken)]

I do see that "nm" warning too -- I didn't dig into it yet. I don't think that's a ninja issue. Will have to see.

I have a fix for the "Power Macintosh" issue that fixes the machine recognition, that was accepted upstream today, so I can patch that too.

I have not seen that "timestamps before 1980" error. Give me an idea where you saw that one? There is some meson ticket in MacPorts about old timestamps.... I guess that is not really a meson issue?

on my Tiger systems, meson uses python38, and doesn't seem to need any more packages to function, but I also see that "gcovr" error -- does that not happen on newer systems? If not, why not?

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

I have not seen that "timestamps before 1980" error. Give me an idea where you saw that one? There is some meson ticket in MacPorts about old timestamps.... I guess that is not really a meson issue?

Yes, it's not a Meson issue, it's consequence of using Apple's gnutar and it only appears when performing env CC='/opt/local/bin/gcc-apple-4.2' ./run_tests.py – possibly the environment needs some more help than just setting CC. And a few of the tests performed are invoking Zip which fail because of the files' date. (They are still running and I need to study their output later.)

on my Tiger systems, meson uses python38, and doesn't seem to need any more packages to function, but I also see that "gcovr" error -- does that not happen on newer systems? If not, why not?

The tests, with Python 3.8 too, need additional packages, at least this one:

root 252 /\ port install py38-jsonschema
--->  Computing dependencies for py38-jsonschema
The following dependencies will be installed: 
 py38-attrs
 py38-importlib-metadata
 py38-pyrsistent
 py38-setuptools_scm
 py38-toml
 py38-zipp

The expressed need for gcovr comes an old gcov from GCC 4.2. Since more up-to-date Macs use Clang they might have an up-to-date gcov version… (I'll check on Catalina and High Sierra.)

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to kencu:

Yes, it's not a Meson issue, it's consequence of using Apple's gnutar and it only appears when performing env CC='/opt/local/bin/gcc-apple-4.2' ./run_tests.py – possibly the environment needs some more help than just setting CC.

Portfile has a whole section on performing the tests which also sets the environment right:

test.env            CXX=${configure.cxx} \
                    "CXXFLAGS=${configure.cxxflags} [get_canonical_archflags cxx]" \
                    CC=${configure.cc} \
                    "CFLAGS=${configure.cflags} [get_canonical_archflags cc]" \
                    "LDFLAGS=${configure.ldflags} [get_canonical_archflags ld]" \
                    PREFIX=${prefix}
test.cmd            ./run_tests.py

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

I do see that "nm" warning too -- I didn't dig into it yet. I don't think that's a ninja issue. Will have to see.

They seem to come out of mesonbuild/scripts/symbolextractor.py. Could be these are the relevant lines:

111:    output = call_tool('nm', ['--dynamic', '--extern-only', '--defined-only',
112:                              '--format=posix', libfilename])
149:    output = call_tool('nm', ['--extern-only', '--defined-only',
150:                              '--format=posix', libfilename])
229:    # Next, try llvm-nm.exe provided by LLVM, then nm.exe provided by MinGW
230:    for nm in ('llvm-nm', 'nm'):
231:        output, e = call_tool_nowarn(get_tool(nm) + ['--extern-only', '--defined-only',
232:                                                     '--format=posix', impfilename])

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to kencu:

root 252 /\ port install py38-jsonschema
…

comes from:

test_validate_json (__main__.InternalTests)
Validate the json schema for the test cases. ... skipped 'Python jsonschema module not found.'

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to kencu:

The expressed need for gcovr comes an old gcov from GCC 4.2. Since more up-to-date Macs use Clang they might have an up-to-date gcov version… (I'll check on Catalina and High Sierra.)

No, I can see on Catalina, Version 10.15.7:

test_coverage (__main__.AllPlatformTests) ... skipped 'gcovr not found, or too old'
test_coverage_complex (__main__.AllPlatformTests) ... skipped 'gcovr not found, or too old'
test_coverage_html (__main__.AllPlatformTests) ... skipped 'gcovr not found, or too old'
test_coverage_text (__main__.AllPlatformTests) ... skipped 'gcovr not found, or too old'
test_coverage_xml (__main__.AllPlatformTests) ... skipped 'gcovr not found, or too old'

[ballapete (Peter "Pete" Dyballa)]

Another problem from programmers who cannot distinguish between lower and upper case:

Looking for framework python in /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks

The Python.framework *does* exist. And a few tests fail because of this.

[ballapete (Peter "Pete" Dyballa)]

Source dir: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_meson/meson/work/meson-0.55.3/test cases/frameworks/4 qt tests for both QT toolkits 4 and 5. It seems the package qt5-qttools is needed:

Run-time dependency qt5 (modules: DefinitelyNotFound) found: NO (tried pkgconfig)
Run-time dependency qt5 (modules: Core, DefinitelyNotFound) found: NO (tried pkgconfig)
Run-time dependency qt5 (modules: Core) found: YES 5.14.2 (pkg-config)
Run-time dependency qt5 (modules: Gui) found: YES 5.14.2 (pkg-config)
Run-time dependency qt5 (modules: Core, Gui, Widgets) found: YES 5.14.2 (pkg-config)
Detecting Qt5 tools
Program /opt/local/libexec/qt5/bin/moc found: YES 5.14.2

Program /opt/local/libexec/qt5/bin/uic found: YES 5.14.2

Program /opt/local/libexec/qt5/bin/rcc found: YES 5.14.2

Program /opt/local/libexec/qt5/bin/lrelease found: NO
Program lrelease-qt5 found: NO
Program lrelease found: NO

test cases/frameworks/4 qt/meson.build:45:4: ERROR: Assert failed: qtmodule.has_tools()

[ballapete (Peter "Pete" Dyballa)]

Could be this is the culprit:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_meson/meson/work/meson-0.55.3/test\ cases/osx/5\ extra\ frameworks/meson.build:9:dep_py = dependency('python', method : 'extraframework')

[kencu (Ken)]

I have the full finished Tiger PPC test run I can upload. It has many errors, of course. But that's to be expected.

nm is warning about an unsupported flag; it's one of those flags you found...perhaps we can find out which one, but it doesn't seem overly important to remove it just now as it's just a warning I think. You'll see hundreds more warnings :)

If you find a port that meson won't build on Tiger (other than atk and at-spi2-*) let me know and I'll take a look with you.

The biggest issue right now is to run gir-* tools, you need to set the dyld_library_path in destroot to the location of the library if it's in a subfol, eg atk, at-spi2-core, and probably more. I'll PR those minor fixes shortly.

[kencu (Ken)]

re gcovr- I can't see us fixing code coverage testing on Tiger any time soon...if it doesn't even work on Catalina!

That's for upstream I guess, if they care about it...

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Could be this is the culprit:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_meson/meson/work/meson-0.55.3/test\ cases/osx/5\ extra\ frameworks/meson.build:9:dep_py = dependency('python', method : 'extraframework')

No, it's run_unittests.py in the src root directory. I have a patch for this…

[ballapete (Peter "Pete" Dyballa)]

Patch file to load the *P*ython Framework during test

[kencu (Ken)]

it might be profitable to split off some of these non-Tiger issues into other tickets, as we're into 31 comments here now and the signal-to-noise ratio about getting some version of meson to run on Tiger is degrading...

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

it might be profitable to split off some of these non-Tiger issues into other tickets, as we're into 31 comments here now and the signal-to-noise ratio about getting some version of meson to run on Tiger is degrading...

True! It's just that my MacBook is a bit faster than my PowerBook. (On Tiger I can see the same Frameworks errors plus some more…) So I can prepare patches there and test them on Tiger.

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to kencu:

I do see that "nm" warning too -- I didn't dig into it yet. I don't think that's a ninja issue. Will have to see.

nm does not accept any opion starting with --. --extern-only can become -g and --defined-only can become -U.

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to ballapete:

Replying to kencu:

Portfile has a whole section on performing the tests which also sets the environment right:

Could be there is also a setting for LD needed – quite many times I see on Tiger Unable to determine dynamic linker. Could be GCC 7 should be used for compilation… (-std=c++11 is checked for, options like -flto are -fsanitize=address are being used during tests)

[ballapete (Peter "Pete" Dyballa)]

The test version of meson @0.55.3 still has a problem with the identity of 'ppc' and 'power macintosh', the latter value comes from uname (with correct case), the other is internal to Meson. This is demonstrated here:

Rejected /opt/local/lib/libz.dylib, supports ['ppc'] but need power macintosh
Rejected /opt/local/lib/libz.a, supports ['ppc'] but need power macintosh
Rejected /usr/lib/libz.dylib, supports ['ppc'] but need power macintosh
Rejected /opt/local/lib/libz.dylib, supports ['ppc'] but need power macintosh
Rejected /opt/local/lib/libz.a, supports ['ppc'] but need power macintosh

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to ballapete:

dependency('python', method : 'extraframework')

The case does *not* seem to be the cause of the failures:

Run-time dependency python found: NO (tried framework)
../.tmp/tmpwulm1y_8/meson.build:2:0: ERROR: Dependency "Python" not found, tried framework

There must be another reason why these frameworks tests fail.

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

If you find a port that meson won't build on Tiger (other than atk and at-spi2-*) let me know and I'll take a look with you.

This is, momentarily, the full list of ports that need Meson, grep'ed off their Portfiles:

devel           atk
gnome           at-spi2-atk
gnome           at-spi2-core
devel           shared-mime-info
------------------------------
audio           libmpdclient
audio           mpc
audio           ncmpc
devel           appstream-glib
devel           girara
devel           libgnt
devel           libhandy
devel           libnotify
devel           libxkbcommon
devel           orc
devel           spice-protocol
devel           spice-server
gnome           devhelp
gnome           eog
gnome           epiphany
gnome           folks
gnome           frogr
gnome           gcab
gnome           gedit
gnome           gedit-plugins
gnome           geocode-glib
gnome           gexiv2
gnome           gitg
gnome           glib-networking
gnome           gnome-backgrounds
gnome           gnome-desktop
gnome           gnome-dictionary
gnome           grilo
gnome           grilo-plugins
gnome           gsettings-desktop-schemas
gnome           gtk-vnc
gnome           gtksourceview4
gnome           gucharmap
gnome           libchamplain
gnome           libdazzle
gnome           libgdata
gnome           libgit2-glib
gnome           libpeas
gnome           libsoup
gnome           mm-common
gnome           spice-gtk
gnome           totem
gnome           totem-pl-parser
graphics        babl
graphics        babl-devel
graphics        gdk-pixbuf2
graphics        gegl
graphics        gegl-devel
graphics        graphene
irc             hexchat
multimedia      dav1d
net             libgweather
net             megatools
net             urbit
office          zathura
office          zathura-plugin-cb
office          zathura-plugin-djvu
office          zathura-plugin-pdf-mupdf
office          zathura-plugin-pdf-poppler
office          zathura-plugin-ps
python          py-gobject3
python          py27-gobject3
science         bali-phy
shells          ksh
www             libhttpseverywhere

Except for the first four ports I am not using any other. I'll try later to build "my" four packages again…

[kencu (Ken)]

atk is fixed:

$ port -v installed atk 
The following ports are currently installed:
  atk @2.36.0_0 (active) platform='darwin 8' archs='ppc' date='2020-10-18T22:28:00-0700'

at-spi2-atk is fixed:

$ port -v installed at-spi2-atk
The following ports are currently installed:
  at-spi2-atk @2.38.0_0 (active) platform='darwin 8' archs='ppc' date='2020-10-18T22:28:38-0700'

at-spi2-core is fixed:

$ port -v installed at-spi2-core
The following ports are currently installed:
  at-spi2-core @2.38.0_0 (active) platform='darwin 8' archs='ppc' date='2020-10-18T22:26:17-0700'

shared-mime-info is fixed:

$ port -v installed shared-mime-info
The following ports are currently installed:
  shared-mime-info @2.0_0 (active) platform='darwin 8' archs='ppc' date='2020-06-26T22:29:03-0700'

The ones that needed a tweak I fixed a couple of days ago in my TigerPorts repo. It is a minor fix now, as meson is pretty solid on Tiger except for one little thing ... I'm just sussing out moving these fixes into the main MacPorts repo.

I probably have lots of the other ones installed already -- if there is one you want, please point it out.

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

On old Macs /usr/bin/nm and /opt/local/bin/nm behave differently and understand different options. '-g' for external symbols and '-P' for POSIX format in output are understood by both, an additional '-t x' is not necessary for hex formatted numbers but accepted by both. Without -U which Apple's nm does not understand also undefined symbols are output but do not harm. So we have a cure for this!

[ballapete (Peter "Pete" Dyballa)]

Patch to make nm work on older Macs

[kencu (Ken)]

Replying to ballapete:

Portfile has a whole section on performing the tests which also sets the environment right:

I put it there ;>

[ballapete (Peter "Pete" Dyballa)]

During test lines à la

.../meson.build:<number>:0: ERROR: Unable to determine dynamic linker.

appear. They probably indicate the absence of the D lang(uage) compiler, or particularly its linker. GCC 9 has D lang support, but port only builds gcc_configure_langs {c c++ objc obj-c++ lto fortran}. These seem to be the D lang(uage) ports:

dmd                            @2.088.0        lang/dmd
dmd-bootstrap                  @2.088.0        lang/dmd-bootstrap
dmd-doc                        @2.088.0        lang/dmd-doc
dmd-tools                      @2.088.0        lang/dmd-tools

[ballapete (Peter "Pete" Dyballa)]

Ken, Meson definitely needs the nm_behave_MacOSX.patch for mesonbuild/scripts/symbolextractor.py in order to correctly invoke nm. I am trying to upgrade the at(k) ports and I am seeing the nm failures.

[kencu (Ken)]

I have no nm patch and see no nm failures at all.

If you're not using my fixed atk and at-spi2-* ports from my tree you will see failures as I haven't uploaded the fixes to MacPorts yet.

[kencu (Ken)]

or maybe there is something else going on as well. email me what happens when you try to install atk for example.

[ballapete (Peter "Pete" Dyballa)]

Replying to kencu:

I have no nm patch and see no nm failures at all.

I am using

  meson @0.55.3_0 platform='darwin 8' archs='noarch' date='2020-10-22T09:45:06+0200'
  meson @0.55.3_1 (active) platform='darwin 8' archs='noarch' date='2020-10-22T11:48:21+0200'

and saw nm complain about a -- option when I test-built atk. I rebuilt your meson @0.55.3_1 with my nm-on-Mac OS X patch and am rebuilding/installing the three at* packages. nm produces no build ERROR, just a WARNING:

'nm' does not work. Relinking will always happen on source changes.
error: nm: invalid argument --
Usage: nm [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch <arch_flag>] ...] [file ...]

[kencu (Ken)]

I never see any nm build failures, even without your nm patch, on two different Tiger systems (one PPC, one Intel) but I do see this:

'nm' does not work. Relinking will always happen on source changes.

which I think is unimportant, although sure, if it's fixable, why not fix it, once we sort out where it is needed. Doesn't look like just a Tiger thing.

[kencu (Ken)]

[384e7502afd4cd07760715f2b16a810849d5ad66/macports-ports]

[ballapete (Peter "Pete" Dyballa)]

Meanwhile

  meson @0.55.3_1 (active) platform='darwin 8' archs='noarch' date='2020-10-22T16:38:21+0200'

built, which also allowed to build some other ports, so this ticket (and possibly #61276?) can be closed