ux-trie fails to build on 10.5.8

[barracuda156]

36-197:~ svacchanda$ sudo port -v install ux-trie
--->  Computing dependencies for ux-trie.
--->  Fetching archive for ux-trie
--->  ux-trie-0.1.9_0+universal.darwin_9.ppc-ppc64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
--->  Attempting to fetch ux-trie-0.1.9_0+universal.darwin_9.ppc-ppc64.tbz2 from http://packages.macports.org/ux-trie
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   126    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
--->  Attempting to fetch ux-trie-0.1.9_0+universal.darwin_9.ppc-ppc64.tbz2 from http://nue.de.packages.macports.org/ux-trie
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   278    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
--->  Attempting to fetch ux-trie-0.1.9_0+universal.darwin_9.ppc-ppc64.tbz2 from http://atl.us.packages.macports.org/ux-trie
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   366    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
--->  Configuring ux-trie
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_ux-trie/ux-trie/work/ux-0.1.9" && /opt/local/bin/python2.7 ./waf configure --prefix=/opt/local --nocache 
Setting top to                           : /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_ux-trie/ux-trie/work/ux-0.1.9 
Setting out to                           : /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_ux-trie/ux-trie/work/ux-0.1.9/build 
Checking for 'g++' (c++ compiler)        : /usr/bin/g++-4.2 
Unpacking gtest                          : yes 
Checking for library pthread             : not found 
The configuration failed
(complete log in /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_ux-trie/ux-trie/work/ux-0.1.9/build/config.log)
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_ux-trie/ux-trie/work/ux-0.1.9" && /opt/local/bin/python2.7 ./waf configure --prefix=/opt/local --nocache 
Exit code: 1
Error: Failed to configure ux-trie: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_ux-trie/ux-trie/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port ux-trie failed

[ryandesign (Ryan Carsten Schmidt)]

Could you attach the config.log, please?

[ryandesign (Ryan Carsten Schmidt)]

The log shows the reason why the pthread test fails is because it tries to compile the test with -Wl,-Bstatic and -Wl,-Bdynamic and the linker doesn't understand those flags:

err: ld: unknown option: -Bstatic

I hadn't heard of -Bstatic or -Bdynamic before. They may not be intended for use on macOS. When I configure this port on macOS 10.15, it succeeds, and it does not try to use those flags.

This port uses the weird waf build system with which I am not very familiar. It looks like the bundled waf python script includes some embedded compressed data at the end. After the configure step has been run, this data has been unpacked into the .waf-1.6.8-3e3391c5f23fbabad81e6d17c63a1b1e directory. Within that directory, within the waflib/Tools directory, I see some scripts including gcc.py and gxx.py that mention -Bstatic and -Bdynamic. I don't know why they're getting used in your situation but not in mine.

You may have to ask the developers of waf for assistance with this.

[barracuda156]

Interestingly, it does build on 10.6.8 as ppc:

Sergey-Fedorovs-Mac-mini:~ svacchanda$ port -v installed ux-trie
The following ports are currently installed:
  ux-trie @0.1.9_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2022-01-25T22:02:21+0800'

[kencu (Ken)]

If you could investigate the difference that lets it build one way but not the other, and report back what it is, perhaps someone might be able to put a fix into the Portfile for that.

[kencu (Ken)]

As you might see, if you would like fixes for 10.6 to build as ppc using rosetta added to macports, you most likely will need to be the one to contribute them.

And then the port maintainer will see how it integrates into the existing port structure. If it is too onerous a fix, you might have to spin off your own repo (that is how TigerPorts came to be). If it is not too onerous, it will likely be included by most port maintainers.

Some will not accept such a fix no matter what, however, as that adds to the maintenance burden and is of value to very very few people.

But alternatively, ports that do build as ppc on 10.6 but not on 10.5 might shed some light on how to fix 10.5, and most port maintainers are supportive still.

[barracuda156]

Replying to kencu:

As you might see, if you would like fixes for 10.6 to build as ppc using rosetta added to macports, you most likely will need to be the one to contribute them.

Thank you. Yes, I agree, that's the case. After you decided not to continue working on 10.6 PPC, I am the only one here to deal with it.

And then the port maintainer will see how it integrates into the existing port structure. If it is too onerous a fix, you might have to spin off your own repo (that is how TigerPorts came to be). If it is not too onerous, it will likely be included by most port maintainers.

I will see examples in port files and try to amend my fixes in a way to make them acceptable (so that they are invoked only in case of 10.6 + ppc). I am not sure yet how to specify case of Rosetta, but in the worst case I think it is safe to assume that it will be either 10.6 PPC or 10.6.8 Rosetta (and nothing in between), and then "OS minor" can be used to trigger Rosetta-specific fixes.

Some will not accept such a fix no matter what, however, as that adds to the maintenance burden and is of value to very very few people.

By the way if I want to share some fixes for 10.6/10.6.8 on Github or Macrumors, how to do it appropriately? For one thing, all initial set up and major software fixes are yours. Secondly, I don't know if there are any formal requirements from Macports side. (In fact I was asked in that thread on Macrumors to write a tutorial how to make Macports work on 10.6 PPC and 10.6.8 Rosetta – essentially that would mean collect your guidelines, simplify them and add Xcode installation steps. I could do that, provided you don't object.)

But alternatively, ports that do build as ppc on 10.6 but not on 10.5 might shed some light on how to fix 10.5, and most port maintainers are supportive still.

If I find such cases, that will be great, as it may revive some interest in 10.6 PPC too.