Undefined reference to Magick when trying to build Octave with GCC - gcc

I'm trying to build Octave 4.2.2 on an Ubuntu 16.04 with GCC 4.9.3 but I get this error :
libinterp/.libs/liboctinterp.so: undefined reference to `Magick::CoderInfo::CoderInfo(std::string const&)'
libinterp/.libs/liboctinterp.so: undefined reference to `Magick::Image::comment() const'
libinterp/.libs/liboctinterp.so: undefined reference to `Magick::CoderInfo::description() const'
libinterp/.libs/liboctinterp.so: undefined reference to `Magick::Image::magick() const'
libinterp/.libs/liboctinterp.so: undefined reference to `Magick::Image::attribute(std::string)'
libinterp/.libs/liboctinterp.so: undefined reference to `Magick::Image::ping(std::string const&)'
I already checked my libs and that's what I have :
graphicsmagick/xenial-updates,xenial-security,now 1.3.23-1ubuntu0.6 amd64 [installed]
graphicsmagick-libmagick-dev-compat/xenial-updates,xenial-updates,xenial-security,xenial-security,now 1.3.23-1ubuntu0.6 all [installed]
imagemagick/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed]
imagemagick-6.q16/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed]
imagemagick-common/xenial-updates,xenial-updates,xenial-security,xenial-security,now 8:6.8.9.9-7ubuntu5.15 all [installed]
libgraphics-magick-perl/xenial-updates,xenial-security,now 1.3.23-1ubuntu0.6 amd64 [installed,automatic]
libgraphicsmagick++-q16-12/xenial-updates,xenial-security,now 1.3.23-1ubuntu0.6 amd64 [installed]
libgraphicsmagick++1-dev/xenial-updates,xenial-security,now 1.3.23-1ubuntu0.6 amd64 [installed]
libgraphicsmagick-q16-3/xenial-updates,xenial-security,now 1.3.23-1ubuntu0.6 amd64 [installed]
libgraphicsmagick1-dev/xenial-updates,xenial-security,now 1.3.23-1ubuntu0.6 amd64 [installed]
libmagick++-6-headers/xenial-updates,xenial-updates,xenial-security,xenial-security,now 8:6.8.9.9-7ubuntu5.15 all [installed,auto-removable]
libmagick++-6.q16-5v5/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed,automatic]
libmagick++-6.q16-dev/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed,auto-removable]
libmagickcore-6-arch-config/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed,automatic]
libmagickcore-6-headers/xenial-updates,xenial-updates,xenial-security,xenial-security,now 8:6.8.9.9-7ubuntu5.15 all [installed,automatic]
libmagickcore-6.q16-2/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed]
libmagickcore-6.q16-2-extra/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed]
libmagickcore-6.q16-dev/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed,automatic]
libmagickwand-6-headers/xenial-updates,xenial-updates,xenial-security,xenial-security,now 8:6.8.9.9-7ubuntu5.15 all [installed,automatic]
libmagickwand-6.q16-2/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed]
libmagickwand-6.q16-dev/xenial-updates,xenial-security,now 8:6.8.9.9-7ubuntu5.15 amd64 [installed,automatic]
libmagickwand-dev/xenial-updates,xenial-updates,xenial-security,xenial-security,now 8:6.8.9.9-7ubuntu5.15 all [installed]
Moreover, I have checked liboctinterp.so :
ldd libinterp/.libs/liboctinterp.so | grep -i magick++
libGraphicsMagick++-Q16.so.12 => /usr/lib/libGraphicsMagick++-Q16.so.12 (0x00007f6c7fa2b000)
nm -C /usr/lib/libGraphicsMagick++-Q16.so.12 | grep -i coderinfo
nm: /usr/lib/libGraphicsMagick++-Q16.so.12: no symbols
nm -D /usr/lib/libGraphicsMagick++-Q16.so.12 | grep -i coderinfo
000000000003e600 T _ZN6Magick9CoderInfoaSERKS0_
000000000003e650 T _ZN6Magick9CoderInfoC1EPKN9MagickLib11_MagickInfoE
000000000003e350 T _ZN6Magick9CoderInfoC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
000000000003e2c0 T _ZN6Magick9CoderInfoC1ERKS0_
000000000003e280 T _ZN6Magick9CoderInfoC1Ev
000000000003e650 T _ZN6Magick9CoderInfoC2EPKN9MagickLib11_MagickInfoE
000000000003e350 T _ZN6Magick9CoderInfoC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
000000000003e2c0 T _ZN6Magick9CoderInfoC2ERKS0_
000000000003e280 T _ZN6Magick9CoderInfoC2Ev
000000000003e530 T _ZN6Magick9CoderInfoD1Ev
000000000003e530 T _ZN6Magick9CoderInfoD2Ev
000000000003e5d0 T _ZNK6Magick9CoderInfo10isReadableEv
000000000003e5e0 T _ZNK6Magick9CoderInfo10isWritableEv
000000000003e5a0 T _ZNK6Magick9CoderInfo11descriptionB5cxx11Ev
000000000003e5f0 T _ZNK6Magick9CoderInfo12isMultiFrameEv
000000000003e570 T _ZNK6Magick9CoderInfo4nameB5cxx11Ev
I have no idea why I got this error.
Thanks for your replies :)
EDIT : I already checked thousands of posts, including this one Error while compiling Octave with GCC which is close to mine, but without any result.
EDIT2 : What I got if I check shared object dependencies with grep for Magick instead of Magick++ :
ldd libinterp/.libs/liboctinterp.so | grep -i magick
libGraphicsMagick++-Q16.so.12 => /usr/lib/libGraphicsMagick++-Q16.so.12 (0x00007f09ff71a000)
libGraphicsMagick-Q16.so.3 => /usr/lib/libGraphicsMagick-Q16.so.3 (0x00007f09ff1bf000)
And the command nm results with nm: /usr/lib/libGraphicsMagick-Q16.so.3: no symbols .

After many tries, the only solution was to rebuild GraphicsMagick.
I hope this post will help other people ! :)

Related

Cargo linker error under MacOS, library "is not mach-o or llvm bitcode for architecture arm64"

I'm having some problems executing the tests in a rust library I've written. cargo check and cargo build run without issue, but when I try to execute the program I get a linker error I'm having some trouble deciphering.
$ cargo test -v
Fresh unicode-xid v0.2.2
Fresh cfg-if v1.0.0
Fresh ppv-lite86 v0.2.16
Fresh ryu v1.0.9
Fresh itoa v1.0.1
Fresh libc v0.2.112
Fresh proc-macro2 v1.0.36
Fresh quote v1.0.14
Fresh getrandom v0.2.3
Fresh gmp-mpfr-sys v1.4.7
Fresh az v1.2.0
Fresh syn v1.0.84
Fresh rand_core v0.6.3
Fresh serde_derive v1.0.133
Fresh rand_chacha v0.3.1
Fresh serde v1.0.133
Fresh rand v0.8.4
Fresh serde_json v1.0.74
Fresh rug v1.14.0
Compiling discus-backend v0.1.0
Running `rustc --crate-name discus_backend --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link -C embed-bitcode=no -C split-debuginfo=unpacked -C debuginfo=2
--test -C metadata=c71e1fcdeaefee0d -C extra-filename=-c71e1fcdeaefee0d --out-dir /Users/alex/Documents/PhD/discus/backend/target/debug/deps -C incremental=/Users/alex/Documents/PhD/discus/backend/target/debug/
incremental -L dependency=/Users/alex/Documents/PhD/discus/backend/target/debug/deps --extern rand=/Users/alex/Documents/PhD/discus/backend/target/debug/deps/librand-fdf71b69660f64cc.rlib --extern rug=/Users/al
ex/Documents/PhD/discus/backend/target/debug/deps/librug-5dfded8345f82a31.rlib --extern serde=/Users/alex/Documents/PhD/discus/backend/target/debug/deps/libserde-3fe66fa2e4f801a1.rlib --extern serde_json=/Users
/alex/Documents/PhD/discus/backend/target/debug/deps/libserde_json-fa4a5cc9d88aac71.rlib -L native=/Users/alex/Documents/PhD/discus/backend/target/debug/build/gmp-mpfr-sys-baf189f7359fe85f/out/lib
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-arch" "arm64" [..ommited a wall of text..]
= note: ld: in /Users/alex/Documents/PhD/discus/backend/target/debug/deps/libgmp_mpfr_sys-fc4a05e05df117d3.rlib(randclr.o), archive member 'randclr.o' with length 496 is not mach-o or llvm bitcode for architucture arm64
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
warning: `discus-backend` (lib test) generated 9 warnings (9 duplicates)
error: could not compile `discus-backend` due to previous error; 9 warnings emitted
I suspect this is some problem with my development environment on MacOS, I've recently migrated from Linux to MacOS, it worked fine on Linux and a continuous integration set up on GitLab runs the tests without a problem.
$ cc -v
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
$ ld -v
ld -v ~
#(#)PROGRAM:ld PROJECT:ld64-711
BUILD 21:57:24 Nov 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.0.0, (clang-1300.0.29.30) (static support for 27, runtime is 27)
TAPI support using: Apple TAPI version 13.0.0 (tapi-1300.0.6.5)
Attempted using different rustup installers, via the official rust installation script, nixpkg, and homebrew. Same problem with each.
If anyone can offer any advice it would be much appreciated! Thanks!
you can try to use x86_64-apple-darwin version of rust.
I found this method from, and it solved my problem.

Cross-compiling kernel tools, cannot find -lelf even with -L set correctly

I'm trying to cross-compile a modified version of the official Debian kernel for armhf on my amd64 machine. I'm using the HowToCrossBuildAnOfficialDebianKernelPackage instructions on the Debian wiki.
The kernel itself builds fine, but I get an error from ld when trying to build objtool for the linux-kbuild package:
# make -f debian/rules.real build-kbuild KBUILD_HOSTLDFLAGS="-L/usr/lib/arm-linux-gnueabihf"
[...]
arm-linux-gnueabihf-gcc /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/objtool-in.o -lelf /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/libsubcmd.a -L/usr/lib/arm-linux-gnueabihf -o /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/objtool
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lelf
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:67: /usr/src/linux.buster-backports/debian/build/build-tools/tools/objtool/objtool] Error 1
You can see that make did add the -L/usr/lib/arm-linux-gnueabihf flag to gcc. And /usr/lib/arm-linux-gnueabihf does contain libelf:
# ls -l /usr/lib/arm-linux-gnueabihf/libelf*
-rw-r--r-- 1 root root 67296 May 28 2019 /usr/lib/arm-linux-gnueabihf/libelf-0.176.so
lrwxrwxrwx 1 root root 15 May 28 2019 /usr/lib/arm-linux-gnueabihf/libelf.so.1 -> libelf-0.176.so
# file /usr/lib/arm-linux-gnueabihf/libelf-0.176.so
/usr/lib/arm-linux-gnueabihf/libelf-0.176.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=51d60560aa6c0538f0bf34c07e4e2bc230c00834, stripped
I installed libelf like this:
dpkg --add-architecture armhf
apt-get update
apt-get install libelf1:armhf
The ld that's being used does appear to be for arm:
# /usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld -V
GNU ld (GNU Binutils for Debian) 2.31.1
Supported emulations:
armelf_linux_eabi
armelfb_linux_eabi
I'm stumped. How do I get ld to link libelf?
Neither libelf-0.176.so nor libelf.so.1 are searched by the -lelf option to the linker. You still need libelf.so file. This file can be created:
By installing libelf-dev package (as usual, the libraries with exact .so are installed by *-dev packages). Make sure to choose a package suitable for cross-compiling.
By creating symlink libelf.so pointed to the libelf-0.176.so file which you have.

Cross-compiling boost 1.7 for ARM Raspberry pi 3

I'm trying to get my boost cross-compilation ready for my raspberry project. I have the cross-compilation of my project up until now running but now I need to start using some boost features.
In order to do that, I'm trying to compile it and I'm following many guides (The main one is this one) but I'm getting some errors while executing the bjam:
./bjam install toolset=gcc-arm --prefix=~/libs/ --disable-long-double --sNO_ZLIB=1 --sNO_BZIP2=1
I have the toolchain recognized with the modification of the project-config.jam file to using gcc : arm : arm-linux-gnueabi-g++ ;
I'm using the WSL debian on my windows 10 for all this. You will see that on the paths.
This the error that I'm getting:
*** argument error
* rule numbers.less ( n1 n2 )
* called with: ( 4 )
* missing argument n2
/mnt/d/Downloads/boost_1_70_0/tools/build/src/util/numbers.jam:66:see definition of rule 'numbers.less' being called
/mnt/d/Downloads/boost_1_70_0/tools/build/src/tools/common.jam:854: in common.format-name
/mnt/d/Downloads/boost_1_70_0/tools/boost_install/boost-install.jam:87: in boost-install.generate-cmake-variant-
/mnt/d/Downloads/boost_1_70_0/tools/build/src/kernel/modules.jam:107: in modules.call-in
/mnt/d/Downloads/boost_1_70_0/tools/build/src/util/indirect.jam:105: in indirect.call
/mnt/d/Downloads/boost_1_70_0/tools/build/src/build/virtual-target.jam:902: in execute
/mnt/d/Downloads/boost_1_70_0/tools/build/src/build/virtual-target.jam:821: in class#action.actualize
/mnt/d/Downloads/boost_1_70_0/tools/build/src/build/virtual-target.jam:332: in actualize-action
/mnt/d/Downloads/boost_1_70_0/tools/build/src/build/virtual-target.jam:518: in actualize-no-scanner
/mnt/d/Downloads/boost_1_70_0/tools/build/src/build/virtual-target.jam:142: in class#virtual-target.actualize
/mnt/d/Downloads/boost_1_70_0/tools/build/src/build-system.jam:810: in load
/mnt/d/Downloads/boost_1_70_0/tools/build/src/kernel/modules.jam:295: in import
/mnt/d/Downloads/boost_1_70_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build
/mnt/d/Downloads/boost_1_70_0/boost-build.jam:17: in module scope
I'm quite lost regarding this. I've been searching for a solution for the last week and I'm giving up now. Does anybody knows what's going on?
I have this compiler and cross-compiler installed:
g++/stable,now 4:6.3.0-4 amd64 [installed,automatic]
g++-6/stable,stable,now 6.3.0-18+deb9u1 amd64 [installed,automatic]
g++-6-arm-linux-gnueabi/stable,now 6.3.0-18cross1 amd64 [installed,automatic]
g++-arm-linux-gnueabi/stable,now 4:6.3.0-4 amd64 [installed]
gcc/stable,now 4:6.3.0-4 amd64 [installed,automatic]
gcc-6/stable,stable,now 6.3.0-18+deb9u1 amd64 [installed,automatic]
gcc-6-arm-linux-gnueabi/stable,now 6.3.0-18cross1 amd64 [installed,automatic]
gcc-6-arm-linux-gnueabi-base/stable,now 6.3.0-18cross1 amd64 [installed,automatic]
gcc-6-base/stable,stable,now 6.3.0-18+deb9u1 amd64 [installed]
gcc-6-cross-base/stable,now 6.3.0-18cross1 all [installed,automatic]
gcc-arm-linux-gnueabi/stable,now 4:6.3.0-4 amd64 [installed]
This can be ignored. It's a bug in the one of the bjam files. You can follow this link for more information

compiling gtk+3 project with msys on windows

I'm trying to compile a C project on windows that has a dependency on gtk+-3.0 (using msys to build it). Here's the list of gtk packages that I installed:
$ pacman -Ss gtk | grep installed
mingw32/mingw-w64-i686-glib2 2.52.3-1 [installed]
mingw32/mingw-w64-i686-gtk3 3.22.18-1 [installed]
mingw32/mingw-w64-i686-gtkmm3 3.22.0-1 [installed]
mingw64/mingw-w64-x86_64-glib2 2.52.3-1 [installed]
msys/glib2 2.48.2-1 [installed]
However, when I run ./configure I get the following error:
checking for GTK... no
configure: error: Package requirements (gtk+-3.0 >= gtk_required_version) were not met:
No package 'gtk+-3.0' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Alternatively, you may set the environment variables GTK_CFLAGS and GTK_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
What did I do wrong?
The problem was due to compiling directly from bash instead of the shell environment setup for building native 32-bit apps (msys2_shell.cmd -mingw32)

All possible GOOS value?

If I get it right, GOOS is determined when compile the source code.
To better support multiple OS, I'm interested in what GOOS could be.
Of course, there might be infinite possibilities of it, since Go is opensourced. So what I really want is a "common list".
Known values are:
windows
linux
darwin or freebsd or unix? I know that at least one of them must exist.
Note that those values are defined in:
src/go/build/syslist.go, and
doc/install/source#environment.
With Go 1.5 (Q3 2015), GOARCH will become much more complete.
See commit 1eebb91 by Minux Ma (minux)
go/build: reserve GOARCH values for all common architectures
Whenever we introduce a new GOARCH, older Go releases won't recognize them and this causes trouble for both our users and us (we need to add unnecessary build tags).
Go 1.5 has introduced three new GOARCHes so far: arm64 ppc64 ppc64le, we can take the time to introduce GOARCHes for all common architectures that Go might support in the future to avoid the problem.
const goosList = "android darwin dragonfly freebsd linux nacl \
netbsd openbsd plan9 solaris windows "
const goarchList = "386 amd64 amd64p32 arm arm64 ppc64 ppc64le \
mips mipsle mips64 mips64le mips64p32 mips64p32le \ # (new)
ppc s390 s390x sparc sparc64 " # (new)
The list is still being review in Change 9644, with comments like:
I wouldn't bother with Itanium. It's basically a dead architecture.
Plus, it's so hard to write a compiler for it that I really can't see it happening except as a labor of love, and nobody loves the Itanium.
The official documentation now (GO 1.5+ Q3 2015) reflects that completed list.
Update 2018: as documented in Giorgos Oikonomou's answer, Go 1.7 (Q1 2016) has introduced the
go tool dist list command.
See commit c3ecded: it fixes issue 12270 opened in Q3 2015:
To easier write tooling for cross compiling it would be good to programmatically get the possible combinations of GOOS and GOARCH.
This was implemented in CL 19837
cmd/dist: introduce list subcommand to list all supported platforms
You can list in plain text, or in json:
> go tool dist list -json
[
{
"GOOS": "android",
"GOARCH": "386",
"CgoSupported": true
},
...
]
As Mark Bates tweeted:
Bonus: Column output properly formatted for display:
go tool dist list | column -c 75 | column -t
I think you're looking for this list of possible GOOS and GOARCH combinations, in this section:
http://golang.org/doc/install/source#environment
$GOOS and $GOARCH
The name of the target operating system and
compilation architecture. These default to the values of $GOHOSTOS and
$GOHOSTARCH respectively (described below).
Choices for $GOOS are darwin (Mac OS X 10.8 and above and iOS),
dragonfly, freebsd, linux, netbsd, openbsd, plan9, solaris and
windows. Choices for $GOARCH are amd64 (64-bit x86, the most mature
port), 386 (32-bit x86), arm (32-bit ARM), arm64 (64-bit ARM), ppc64le
(PowerPC 64-bit, little-endian), ppc64 (PowerPC 64-bit, big-endian),
mips64le (MIPS 64-bit, little-endian), and mips64 (MIPS 64-bit,
big-endian). mipsle (MIPS 32-bit, little-endian), and mips (MIPS
32-bit, big-endian).
The valid combinations of $GOOS and $GOARCH are:
$GOOS $GOARCH
android arm
darwin 386
darwin amd64
darwin arm
darwin arm64
dragonfly amd64
freebsd 386
freebsd amd64
freebsd arm
linux 386
linux amd64
linux arm
linux arm64
linux ppc64
linux ppc64le
linux mips
linux mipsle
linux mips64
linux mips64le
netbsd 386
netbsd amd64
netbsd arm
openbsd 386
openbsd amd64
openbsd arm
plan9 386
plan9 amd64
solaris amd64
windows 386
windows amd64
You can see the list of supported platform by running:
go tool dist list
and this will print(depending on the Go version):
android/386
android/amd64
android/arm
android/arm64
darwin/386
darwin/amd64
darwin/arm
darwin/arm64
dragonfly/amd64
freebsd/386
freebsd/amd64
freebsd/arm
linux/386
linux/amd64
linux/arm
linux/arm64
linux/mips
linux/mips64
linux/mips64le
linux/mipsle
linux/ppc64
linux/ppc64le
linux/s390x
nacl/386
nacl/amd64p32
nacl/arm
netbsd/386
netbsd/amd64
netbsd/arm
openbsd/386
openbsd/amd64
openbsd/arm
plan9/386
plan9/amd64
plan9/arm
solaris/amd64
windows/386
windows/amd64
And the official documentation for the tool:
https://godoc.org/github.com/golang/go/src/cmd/dist
To cross compile use:
GOOS=darwin GOARCH=386 go build main.go

Resources