Opened 3 years ago
Closed 3 years ago
#64087 closed defect (invalid)
ImageMagick @7.1.0-16: Undefined symbols _clBuildProgram _clCreateBuffer _clCreateCommandQueue
Reported by: | gaming-hacker (G Alexander) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | Cc: | ||
Port: | ImageMagick |
Description (last modified by gaming-hacker (G Alexander))
Hello,
I am building imagemagick for osx 10.13 and only build for x86_64 so in the macports.conf I have specified
build_arch x86_64 universal_archs x86_64 x86_64
in the variants.conf I have specified
-universal
This macports should now build for x86_64 to my understanding. But here is part of the log file;
version:1 :debug:main Starting logging for ImageMagick :debug:sysinfo macOS 10.13.6 (darwin/17.7.0) arch i386 :debug:sysinfo MacPorts 2.7.1 :debug:sysinfo Xcode 9.3.1 :debug:sysinfo SDK 10.13 :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.13
as can be seen somehow macports is picking up i386 initially while later on in the build
:info:build libtool: compile: /usr/bin/clang++ -DHAVE_CONFIG_H -I. -I./config -I. -I. -I./Magick++/lib -I/opt/local/include -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=64 -pipe -Os -stdlib=libc++ -arch x86_64 -pthread -MT Magick++/lib/libMagick___7_Q64HDRI_la-Montage.lo -MD -MP -MF Magick++/lib/.deps/libMagick___7_Q64HDRI_la-Montage.Tpo -c Magick++/lib/Montage.cpp -o Magick++/lib/libMagick___7_Q64HDRI_la-Montage.o >/dev/null
It is clearly building x86_64.
Now the build finally bombs on opencl
:info:build Undefined symbols for architecture x86_64: :info:build "_clBuildProgram", referenced from: :info:build _InitializeOpenCL in libMagickCore_7_Q64HDRI_la-opencl.o :info:build "_clCreateBuffer", referenced from: :info:build _InitializeOpenCL in libMagickCore_7_Q64HDRI_la-opencl.o :info:build "_clCreateCommandQueue", referenced from: :info:build _InitializeOpenCL in libMagickCore_7_Q64HDRI_la-opencl.o
How to disable or otherwise force macports here to accept x86_64 builds and no i386 build without updating to 10.14? I have successfully built ffmpeg with opencl so I know that opencl x86_64 is not broken.
:debug:sysinfo macOS 10.13.6 (darwin/17.7.0) arch i386
Attachments (1)
Change History (6)
comment:1 Changed 3 years ago by gaming-hacker (G Alexander)
Summary: | Bug detecting correct arch for 10.13 → Bug detecting incorrect arch for 10.13 |
---|
comment:2 Changed 3 years ago by gaming-hacker (G Alexander)
Description: | modified (diff) |
---|
comment:3 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Component: | base → ports |
---|---|
Keywords: | arch detection SDK universal removed |
Port: | ImageMagick added |
Summary: | Bug detecting incorrect arch for 10.13 → ImageMagick: Undefined symbols _clBuildProgram _clCreateBuffer _clCreateCommandQueue |
Changed 3 years ago by gaming-hacker (G Alexander)
logfile from imagemagick build
comment:4 Changed 3 years ago by gaming-hacker (G Alexander)
Thanks a lot for the clarification.
I'll just clone the imagemagick repo and build it from there. Since it's not a bug, please close ticket. I've attached the log file if anyone is still interested.
comment:5 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → invalid |
---|---|
Status: | new → closed |
Summary: | ImageMagick: Undefined symbols _clBuildProgram _clCreateBuffer _clCreateCommandQueue → ImageMagick @7.1.0-16: Undefined symbols _clBuildProgram _clCreateBuffer _clCreateCommandQueue |
The log shows that you're trying to build ImageMagick 7.1.0, which is not offered in MacPorts at this time. See #51310.
You appear to be using a local Portfile in /Users/glen/local/repo/macports/graphics/ImageMagick. You'll have to ask whoever wrote that Portfile for assistance in getting it to work.
Replying to gaming-hacker:
It's not valid to specify the same arch twice in universal_archs. The correct value for universal_archs for 10.13 is i386 x86_64.
This is the variable os.arch. Its only possible values are i386 (meaning any Intel processor), powerpc (meaning any PowerPC processor), or arm (meaning any ARM processor). It does not indicate the bitness.
This is unrelated to the
-arch
flags that you see in the build that do relate to the bitness.This naming confusion between the two different meanings of "arch" in MacPorts is unfortunate.
Please attach the main.log so that we can diagnose why this happened.