apr-util doesn't always use -arch flags

[rmottola (Riccardo)]

while upgrading serf1 on Leopard 64bit, I get the following error:

ld: warning: ignoring file /opt/local/lib/libaprutil-1.dylib, file was built for unsupported file format which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
  "_apr_uri_unparse", referenced from:
      _serf_connection_create2 in outgoing.os
  "_apr_uri_parse", referenced from:
      _serf_connection_create2 in outgoing.os
      _serf__setup_request_digest_auth in auth_digest.os
  "_apr_uri_port_of_scheme", referenced from:
      _serf_connection_create2 in outgoing.os
  "_apr_date_checkmask", referenced from:
      _run_machine.isra.2 in bwtp_buckets.os
      _run_machine.isra.3 in response_buckets.os
  "_apr_base64_encode_len", referenced from:
      _serf_ssl_cert_export in ssl_buckets.os
      _serf__encode_auth_header in auth.os
  "_apr_base64_encode", referenced from:
      _serf_ssl_cert_export in ssl_buckets.os
      _serf__encode_auth_header in auth.os
  "_apr_uuid_get", referenced from:
      _serf__setup_request_digest_auth in auth_digest.os
  "_apr_uuid_format", referenced from:
      _serf__setup_request_digest_auth in auth_digest.os
  "_apr_md5", referenced from:
      _build_digest_ha2 in auth_digest.os
      _serf__handle_digest_auth in auth_digest.os
      _serf__setup_request_digest_auth in auth_digest.os
      _serf__validate_response_digest_auth in auth_digest.os
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

indeed, if I execute

$ file /opt/local/lib/libaprutil-1.dylib
/opt/local/lib/libaprutil-1.dylib: Mach-O dynamically linked shared library i386

it looks that for some reason I got a 32bit version of libaprutil

I think the bug is more in apr that builds with the wrong arch (maybe on 10.5 default is still 32bit) than serf1 which tries to use it, but feel free to correct me.

[rmottola (Riccardo)]

I tried rebuilding apr by forcing clang 7 compiler but I still get a 32bit dylib

[ryandesign (Ryan Carsten Schmidt)]

What's the output of:

port -v installed apr

[rmottola (Riccardo)]

$ port -v installed apr
The following ports are currently installed:
  apr @1.6.5_0 requested_variants='' platform='darwin 9' archs='x86_64' date='2019-06-21T01:56:46+0200'
  apr @1.7.0_0 requested_variants='' platform='darwin 9' archs='x86_64' date='2019-07-27T20:09:54+0200'
  apr @1.7.0_1 requested_variants='' platform='darwin 9' archs='x86_64' date='2020-10-08T00:10:13+0200'
  apr @1.7.0_2 requested_variants='' platform='darwin 9' archs='x86_64' date='2021-03-11T03:14:40+0100'
  apr @1.7.0_3 requested_variants='' platform='darwin 9' archs='x86_64' date='2021-09-17T11:03:14+0200'
  apr @1.7.0_4 requested_variants='' platform='darwin 9' archs='x86_64' date='2023-01-18T08:31:44+0100'
  apr @1.7.2_0 (active) requested_variants='' platform='darwin 9' archs='x86_64' date='2023-03-15T01:47:05+0100'

sounds the correct version is requested, but then the actual library doesn't match. Also all versions have all been 64bit.

[rmottola (Riccardo)]

I wonder if there is a relationship with #66018 In ken's comment there are hints about architecture, so maybe somehow was build wrongly, on older OSs where 32bit is still the default and I am on 64bit.

[ryandesign (Ryan Carsten Schmidt)]

Excuse me, I asked you about the apr port but I should have asked you about the apr-util port:

port -v installed apr-util

[rmottola (Riccardo)]

port -v installed apr-util

  apr-util @1.6.1_2 requested_variants='' platform='darwin 9' archs='x86_64' date='2019-06-21T01:58:10+0200'
  apr-util @1.6.3_0 (active) requested_variants='' platform='darwin 9' archs='x86_64' date='2023-03-06T22:37:52+0100'

looks fine for me at a first glance

[ryandesign (Ryan Carsten Schmidt)]

Ok, so MacPorts thinks it has installed x86_64 versions of both ports:

Replying to rmottola:

  apr @1.7.2_0 (active) requested_variants='' platform='darwin 9' archs='x86_64' date='2023-03-15T01:47:05+0100'

Replying to rmottola:

  apr-util @1.6.3_0 (active) requested_variants='' platform='darwin 9' archs='x86_64' date='2023-03-06T22:37:52+0100'

But you actually have an i386 version of libaprutil:

Replying to rmottola:

/opt/local/lib/libaprutil-1.dylib: Mach-O dynamically linked shared library i386

So one of two things has happened:

1. The correct -arch flags were not used during the build so the default architecture i386 was used.
2. The correct -arch flags were used during the build and then later something overwrote the files MacPorts installed.

I tried building apr-util on my Monterey system and then I looked at the log to see if there were any compiler invocation lines that did not use -arch flags:

port log apr-util | grep -Ev -- ' -arch |libtool ' | grep --color bin/clang

No compiler invocation lines were shown by that command (except two that generate Expect scripts, for which -arch flags would not be needed) so I suspect that option (2) has happened.

libaprutil requires libapr to build, so it should not have been possible to build an i386 version of libaprutil unless you also had an i386 version of libapr. What's the output of:

file /opt/local/lib/libapr-1.dylib

If it shows i386, then try rebuilding apr:

sudo port clean apr
sudo port -nk upgrade --force apr

The -k flag keeps the work directory and log. Do you now have an x86_64 library? If so, that confirms that (2) occurred and you can delete the work directory and log with sudo port clean apr. But if you still have an i386 library, that points to (1); in that case, please attach the main.log file. (port logfile apr)

If libapr was already x86_64, then only libaprutil remains to be fixed; perform the above steps substituting "apr-util" in place of "apr".

[rmottola (Riccardo)]

file /opt/local/lib/libapr-1.dylib
/opt/local/lib/libapr-1.dylib: Mach-O 64-bit dynamically linked shared library x86_64

would confirm that only libaprutil has to be fixed.... rebuilding apr-util as suggested and report

[rmottola (Riccardo)]

ok, rebuilt.... but still

file /opt/local/lib/libaprutil-1.dylib
/opt/local/lib/libaprutil-1.dylib: Mach-O dynamically linked shared library i386

so, it persists, I attach the logfile. I see -arch x86_64 and -m64 used in configure.

However in several lines with libtool like this:

:info:build /bin/sh /opt/local/share/apr-1/build/libtool --silent --mode=compile --tag=CC /usr/bin/gcc-4.2 -std=gnu99   -pipe -Os  -DHAVE_CONFIG_H  -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK  -I/opt/local/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_apr-util/apr-util/work/apr-util-1.6.3/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_apr-util/apr-util/work/apr-util-1.6.3/include/private -I/opt/local/include  -I/opt/local/include/apr-1  -I/opt/local/include  -o dbm/apr_dbm_berkeleydb.lo -c dbm/apr_dbm_berkeleydb.c && touch dbm/apr_dbm_berkeleydb.lo

the compiler is used without any options so I bet it is producing 32bit... IIRC, Leopard had 64bit optional and without flags defaults to 32bit. On Monterey you have 64 bit only

[rmottola (Riccardo)]

build, default system compiler

[ryandesign (Ryan Carsten Schmidt)]

Replying to rmottola:

the compiler is used without any options so I bet it is producing 32bit... IIRC, Leopard had 64bit optional and without flags defaults to 32bit. On Monterey you have 64 bit only

Yes. And I agree that your log shows -arch flags are not being used. On my Monterey system, however, -arch flags were used. I'm not sure what accounts for this discrepancy.

Has duplicate #67368.

[barracuda156]

Replying to ryandesign:

Replying to rmottola:

the compiler is used without any options so I bet it is producing 32bit... IIRC, Leopard had 64bit optional and without flags defaults to 32bit. On Monterey you have 64 bit only

Yes. And I agree that your log shows -arch flags are not being used. On my Monterey system, however, -arch flags were used. I'm not sure what accounts for this discrepancy.

Has duplicate #67368.

BTW, even passing them with configure.cflags is ignored.

UPD. Manually sticking archflags into Makefile.in works.

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

BTW, even passing them with configure.cflags is ignored.

The log shows they are already in CFLAGS etc. And yet they are not used, for unknown reasons.

[rmottola (Riccardo)]

Replying to barracuda156:

how and which archflags do you manually stick in to the port file?

This issue is biting me again... since the upgrade had the same bug.

[jmroot (Joshua Root)]

potential fix

[danielluke (Daniel J. Luke)]

apr-util uses the libtool installed by the apr port - can someone with darwin 9 try jmroot's patch, but with those changes applied to the apr port - then rebuild apr and try to build apr-util?

I /think/ that should fix it, but it's a somewhat unusual configuration to be building the non-default arch (and I don't have a darwin 9 system to test with). I can provide a patch that will apply cleanly if it would help.

[danielluke (Daniel J. Luke)]

Oh, actually please just try jmroot's patch to apr-util. The 'right' fix is to just apply to the apr-util build so that it follows whatever the current architecture that MacPorts expects (regardless of what apr was built with).

[danielluke (Daniel J. Luke)]

... and I can see that that patch correctly puts the -arch flags in the build on my system, so I guess I can assume it'll work elsewhere too :)

If the original reporter can confirm, that will be great - but I'll go ahead and commit with revbump to force rebuild for anyone else who's in this situation.

[rmottola (Riccardo)]

Sorry, didn't check... tried out now. I see jmroot patch in - albeit a little bit out of indentation. I am not building universal. Since the revision bump, I did rebuild.

/opt/local/lib/libaprutil-1.dylib is now x86_64!

Then I go to rebuild serf1... and it fails. But I am pretty convinced that the issue is now serf1, which is trying to build a 32bit version against 64bit libraries! I open a separate bug... and once that builds we can confirm both, but I think apr-util is fine now

[rmottola (Riccardo)]

#68570

[ryandesign (Ryan Carsten Schmidt)]

Replying to danielluke:

I'll go ahead and commit with revbump to force rebuild for anyone else who's in this situation.

It was committed in [84511d50c08edead71cfc42eb6e8f2eff139d820/macports-ports], thus resolving this ticket.

It would have been simpler to just do:

variant universal {}

build.args		EXTRA_CFLAGS="[get_canonical_archflags cc]" \
			EXTRA_LDFLAGS="[get_canonical_archflags ld]"

since get_canonical_archflags already knows about the distinction between universal and non-universal builds, provided that the portfile has declared in advance that a universal variant exists.