[MacPorts] #67101: serf1 fails due to architecture mismatch on apr

[MacPorts]

#67101: serf1 fails due to architecture mismatch on apr
-----------------------+------------------------------
  Reporter:  rmottola  |      Owner:  danielluke
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:  lion x86_64 i386
      Port:  apr-util  |
-----------------------+------------------------------

Comment (by ryandesign):

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

 Replying to [comment:3 rmottola]:
 > {{{
 >   apr @1.7.2_0 (active) requested_variants='' platform='darwin 9'
 archs='x86_64' date='2023-03-15T01:47:05+0100'
 > }}}

 Replying to [comment:6 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 [ticket:67101 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".

-- 
Ticket URL: <https://trac.macports.org/ticket/67101#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS