Opened 14 months ago
Closed 6 months ago
#67101 closed defect (fixed)
apr-util doesn't always use -arch flags
Reported by: | rmottola (Riccardo) | Owned by: | danielluke (Daniel J. Luke) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | lion x86_64 i386 | Cc: | barracuda156 |
Port: | apr-util |
Description
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.
Attachments (2)
Change History (21)
comment:1 Changed 14 months ago by rmottola (Riccardo)
comment:2 Changed 14 months ago by ryandesign (Ryan Carsten Schmidt)
What's the output of:
port -v installed apr
comment:3 Changed 14 months ago by 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.
comment:4 Changed 14 months ago by 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.
comment:5 Changed 14 months ago by ryandesign (Ryan Carsten Schmidt)
Port: | apr-util added; apr removed |
---|
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
comment:6 Changed 13 months ago by 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
comment:7 Changed 13 months ago by 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:
- The correct
-arch
flags were not used during the build so the default architecture i386 was used. - 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".
comment:8 Changed 13 months ago by 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
comment:9 follow-up: 10 Changed 13 months ago by 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
Changed 13 months ago by rmottola (Riccardo)
build, default system compiler
comment:10 follow-up: 11 Changed 12 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | barracuda156 added |
---|---|
Summary: | serf1 fails due to architecture mismatch on apr → apr-util doesn't always use -arch flags |
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.
comment:11 follow-ups: 12 13 Changed 12 months ago by 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.
comment:12 Changed 12 months ago by 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.
comment:13 Changed 7 months ago by 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.
Changed 7 months ago by jmroot (Joshua Root)
Attachment: | Portfile-apr-util.diff added |
---|
potential fix
comment:14 Changed 7 months ago by 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.
comment:15 Changed 7 months ago by 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).
comment:16 follow-up: 19 Changed 7 months ago by 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.
comment:17 Changed 6 months ago by 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
comment:18 Changed 6 months ago by rmottola (Riccardo)
comment:19 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
I tried rebuilding apr by forcing clang 7 compiler but I still get a 32bit dylib