#60018 closed defect (fixed)
libjpeg-turbo @2.0.3+universal: Undefined symbols for architecture x86_64
Reported by: | Cor0n4V1rus | Owned by: | larryv (Lawrence Velázquez) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | metbic, mascguy (Christopher Nielsen), jmroot (Joshua Root), JDLH (Jim DeLaHunt), MaddTheSane (C.W. Betts) | |
Port: | libjpeg-turbo |
Description
judging from the build log, maybe it's because the cmake execution is not correct for a +universal build, despite the -DCMAKE_OSX_ARCHITECTURES="x86_64;i386" parameter:
...
32-bit build (i386)
...
CMAKE_ASM_NASM_OBJECT_FORMAT = macho
CMAKE_ASM_NASM_FLAGS = -DMACHO -DPIC
SIMD extensions: i386 (WITH_SIMD = 1)
files containing the functions the linker cannot find are compiled with nasm with the '-f macho' option, therefore i386-only.
"nasm -hf" states:
...
valid output formats for -f are (`*' denotes default):
...
macho32 NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (i386) object files
macho64 NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (x86_64) object files
...
macho MACHO (short name for MACHO32)
...
the used nasm is the one from macports:
/opt/local/bin/nasm -v
NASM version 2.14.02 compiled on Jan 27 2020
a quick test, compiling the first file "jsimdcpu.asm" with nasm and
"-f macho32 -f macho64"
showed, that only the last -f option is used, therefore only one architecture per compilation unit possible. maybe, for +universal, the whole project has to be compiled twice and then merged with lipo!?
Attachments (2)
Change History (17)
Changed 5 years ago by Cor0n4V1rus
Attachment: | libjpeg-turbo.log.gz added |
---|
comment:1 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | larryv@… removed |
---|---|
Owner: | set to larryv |
Status: | new → assigned |
Summary: | libjpeg-turbo @ 2.0.3 +universal : Undefined symbols for architecture x86_64 → libjpeg-turbo @2.0.3+universal: Undefined symbols for architecture x86_64 |
comment:2 Changed 4 years ago by jmroot (Joshua Root)
Cc: | metbic added |
---|
comment:3 Changed 4 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:4 Changed 4 years ago by JDLH (Jim DeLaHunt)
I am experiencing this bug, attempting to upgrade port tiff @4.2.0_0+universal1
to @4.2.0_1
, which in turn rebuilds libjpeg-turbo-2.0.4_0+universal
. I am using MacPorts version 2.6.4 on macOS 10.13.6 High Sierra.
comment:5 follow-up: 8 Changed 4 years ago by jmroot (Joshua Root)
A couple of things to try:
- 2.0.6 update: https://github.com/macports/macports-ports/pull/9760
- Try disabling use of nasm when building universal? That could be accomplished by making this change (diff against the 2.0.6 Portfile):
-
graphics/libjpeg-turbo/Portfile
diff --git a/graphics/libjpeg-turbo/Portfile b/graphics/libjpeg-turbo/Portfile index e78fc7c1764..2eff408b042 100644
a b checksums sha1 5406c7676d7df89fb4da791ad5af51202910fb25 \ 32 32 sha256 d74b92ac33b0e3657123ddcf6728788c90dc84dcb6a52013d758af3c4af481bb \ 33 33 size 2192315 34 34 35 if {${build_arch} in {i386 x86_64} || ([variant_isset universal] && 36 ("x86_64" in ${universal_archs} || "i386" in ${universal_archs}))} { 35 if {${build_arch} in {i386 x86_64} && ![variant_isset universal]} { 37 36 depends_build-append port:nasm 38 37 39 38 configure.env ASM_NASM=${prefix}/bin/nasm
-
If all else fails, we'll just have to enable muniversal.
comment:6 Changed 4 years ago by jmroot (Joshua Root)
Cc: | jmroot added |
---|
Changed 4 years ago by JDLH (Jim DeLaHunt)
Attachment: | libjpeg-turbo@2.0.4_0+universal.log.gz added |
---|
GZip compressed archive of /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_libjpeg-turbo/libjpeg-turbo/main.log for @2.0.4_0+universal
comment:7 Changed 4 years ago by JDLH (Jim DeLaHunt)
Cc: | JDLH added |
---|
comment:8 Changed 4 years ago by JDLH (Jim DeLaHunt)
Replying to jmroot:
A couple of things to try:
- 2.0.6 update: https://github.com/macports/macports-ports/pull/9760
- Try disabling use of nasm when building universal?
… [snip] …
Thank you for the suggestions, @jmroot. I'll give them a try in a day or two, and report back.
comment:9 follow-up: 10 Changed 4 years ago by metbic
How come this bug lounged around for like a year, with no one else bothering, and then, all of a sudden, emerges?
comment:10 Changed 4 years ago by mascguy (Christopher Nielsen)
Replying to metbic:
How come this bug lounged around for like a year, with no one else bothering, and then, all of a sudden, emerges?
Until today, libjpeg-turbo wasn't utilized. Now that it's in play, we're all rallying to quickly fix these issues.
comment:11 Changed 4 years ago by MaddTheSane (C.W. Betts)
Cc: | MaddTheSane added |
---|
comment:12 Changed 4 years ago by kencu (Ken)
I put a fix for the x86_64/arm64 universal build, at least, in Josh's PR <https://github.com/macports/macports-ports/pull/9760>
% port -v installed libjpeg-turbo The following ports are currently installed: libjpeg-turbo @2.0.6_0+universal (active) platform='darwin 20' archs='arm64 x86_64' date='2021-01-18T17:50:56-0800'
so far, I have only built this universal on an Intel system.
comment:13 Changed 4 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:14 Changed 4 years ago by MaddTheSane (C.W. Betts)
I'm still having issues building the universal version on arm64. It's trying to build jsimd_neon.S
as a universal arm64 and x86_64 assembly file.
Maybe we do need to configure this port in separate directories then lipo it together, or the MacPorts rsync server hasn't been updated yet.
edit: looks like rsync hasn't updated. Ignore.
comment:15 Changed 4 years ago by JDLH (Jim DeLaHunt)
libjpeg-turbo @2.0.6_0+universal
built successfully. Then tiff @4.2.0_1+universal
, which depends on it, built successfully. This on the MacPorts version 2.6.4 on macOS 10.13.6 High Sierra, on which it failed earlier today per comment:4 . A couple dozen ports are now lined up to rebuild. Thank you for the fix!
Replying to Cor0n4V1rus:
That would happen if the Portfile used "PortGroup muniversal 1.0", but it currently doesn't.