Why compiling with musl on Alpine fails and on ArchLinux succeeds - compilation

This is a curiosity question: why?
Why does it have a different behavior for the exact same code?
I often have the issue that I can compile something in one distribution but not in another. So today I bumped into one of those issue again where when I build in the same way PostgreSQL's pg_dump with ArchLinux it works, but when I do it on Alpine it fails with this error:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -static -fPIC -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fPIC -shared -Wl,-soname,libpq.so.5 -Wl,--version-script=exports.list -o libpq.so.5.11 fe-auth.o fe-auth-scram.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o fe-secure.o libpq-events.o chklocale.o inet_net_ntop.o noblock.o pgstrcasecmp.o pqsignal.o thread.o getpeereid.o pg_strong_random.o encnames.o wchar.o base64.o ip.o md5.o scram-common.o saslprep.o unicode_norm.o sha2.o -L../../../src/port -L../../../src/common -Wl,--as-needed -Wl,-rpath,'/usr/local/pgsql/lib',--enable-new-dtags
/lib/gcc/x86_64-linux-musl/8.2.0/../../../../x86_64-linux-musl/bin/ld: /lib/gcc/x86_64-linux-musl/8.2.0/crtbeginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
/lib/gcc/x86_64-linux-musl/8.2.0/../../../../x86_64-linux-musl/bin/ld: /lib/gcc/x86_64-linux-musl/8.2.0/crtend.o: relocation R_X86_64_32 against `.ctors' can not be used when making a shared object; recompile with -fPIC
/lib/gcc/x86_64-linux-musl/8.2.0/../../../../x86_64-linux-musl/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[1]: Leaving directory '/src/src/interfaces/libpq'
make[1]: *** [../../../src/Makefile.shlib:309: libpq.so.5.11] Error 1
make: *** [../../../src/Makefile.global:580: submake-libpq] Error 2
Here is the Dockerfile for Alpine:
FROM muslcc/x86_64:x86_64-linux-musl
RUN apk update && apk add make
ENV DOWNLOAD_URL https://ftp.postgresql.org/pub/source/v11.2/postgresql-11.2.tar.bz2
WORKDIR /src
RUN wget "$DOWNLOAD_URL" && \
tar xvjf "${DOWNLOAD_URL##*/}" --strip-components=1 && \
rm -fv "${DOWNLOAD_URL##*/}"
# NOTE: I left the -fPIC here for clarity sake but it fails with
# the same error with or without it
RUN ./configure --without-readline --without-zlib CFLAGS="-static -fPIC"
RUN cd src/bin/pg_dump && make pg_dump
Here is the Dockerfile for ArchLinux:
FROM archlinux/base
RUN pacman -Syu --noconfirm --needed base-devel musl
ENV DOWNLOAD_URL https://ftp.postgresql.org/pub/source/v11.2/postgresql-11.2.tar.bz2
WORKDIR /src
RUN curl -o "${DOWNLOAD_URL##*/}" "$DOWNLOAD_URL" && \
tar xvjf "${DOWNLOAD_URL##*/}" --strip-components=1 && \
rm -fv "${DOWNLOAD_URL##*/}"
RUN ./configure --without-readline --without-zlib CC="musl-gcc" CFLAGS="-static"
RUN cd src/bin/pg_dump && make pg_dump
I don't even know where to look at. Could it be a difference of version of musl? Another compiling tool? I don't really want the solution, I want to understand why.

I don't have that much experience with Alpine Linux and I would need to play with it myself, but it seems some pretty basic standard C libraries are built as non-platform-independent-code (PIC), which means you aren't allowed to link a dynamic library with it.
I'd start chasing Alpine Linux developers about this, because there are probably configuration flags for PostgreSQL which would allow you to build what you want.
Now, I've notices one thing. You pass CFLAGS=-static to the compilation, but it's pointless as ./configure already set it up as shared - look carefully at the compiler invocation you quote. If you want static build, you need to find a proper configuration flag and use it with ./configure. I your case --disable-shared should work.
CFLAGS="-static" CXXFLAGS="-static" LDFLAGS="-Wl,-Bstatic" ./configure --without-readline --without-zlib
seem to enable -static without leaving -shared.

Related

Modifying configure.ac - check for package presence

My main development platform is Gentoo on Linux. However, recently I tried to build my program on the fresh VM install on Debian.
My program contains of main binary and couple of dll/so/dylib libraries. One of the libraries depends on the presence of unixODBC/iODBC.
I was told by unixODBC maintainers to use odbc_config script to identify the build parameters.
When I build on Gentoo - everything works fine. There is no problems.
However, when I build on Debian - the build fails because apparently Debian does not produce odbc_config script and instead in this case rely on pkg-config.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation (lets call it libodbc_lib project).
Could someone please help me with this?
EDIT:
Is this correct to be put in configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
If it is - how do I use ODBC_FLAGS/ODBC_LIBS in my subproject?
EDIT2:
Based on this answer I used the following code:
In the main configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
In the libodbc_lib/Makefile.am:
libodbc_lib_la_CXXFLAGS = -I../../dbinterface \
-DUNICODE \
-DUNIXODBC \
-I#ODBC_CFLAGS#
libodbc_lib_la_LDFLAGS = -L../dbinterface \
-ldbinterface \
#ODBC_LIB#
I regenerated configure, run it successfully and then tried running make.
I got following error:
CXXLD libodbc_lib.la
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find #ODBC_LIB#: No such file or directory
What I did wrong?
EDIT3:
After fixing the missing S, I got following compile commands:
make[2]: Entering directory '/home/igor/dbhandler/Debug/libodbc'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c -o libodbc_lib_la-database_odbc.lo `test -f 'database_odbc.cpp' || echo '/home/igor/dbhandler/libodbc/'`database_odbc.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -fPIC -DPIC -o .libs/libodbc_lib_la-database_odbc.o
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -o libodbc_lib_la-database_odbc.o >/dev/null 2>&1
mv -f .deps/libodbc_lib_la-database_odbc.Tpo .deps/libodbc_lib_la-database_odbc.Plo
/bin/sh ../libtool --tag=CXX --mode=link g++ -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -L../dbinterface -ldbinterface -o libodbc_lib.la -rpath /usr/local/lib libodbc_lib_la-database_odbc.lo
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtbeginS.o .libs/libodbc_lib_la-database_odbc.o -L../dbinterface -ldbinterface -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crtn.o -g -O0 -Wl,-soname -Wl,libodbc_lib.so.0 -o .libs/libodbc_lib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so.0" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so.0")
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so")
libtool: link: ar cru .libs/libodbc_lib.a libodbc_lib_la-database_odbc.o
libtool: link: ranlib .libs/libodbc_lib.a
libtool: link: ( cd ".libs" && rm -f "libodbc_lib.la" && ln -s "../libodbc_lib.la" "libodbc_lib.la" )
make[2]: Leaving directory '/home/igor/dbhandler/Debug/libodbc'
I still the variable name there and not their values.
Is it normal?
As UnixODBC upstream does ship and install *.pc files, I would expect that file to be both present and correct and therefore I would ignore any *-config scripts. The pkg-config system is quite well thought out and works even for quite weird cross compilation environments. The *.pc mechanism works well on Linux, on FreeBSD, on OSX, cross-compiling for Windows on Linux, to name a few.
A well-written _config program written in portable shell could do the same by basically reproducing much of the pkg-config logic in portable shell for each and every _config script, hopefully correctly.
However, odbc_config is not a portable shell script. It is a binary executable, i.e. it will regularly break for cross-compiling, as the system you build on will usually not be able to run programs like odbc_config which are built to run on the system you are building for.
And even if the flags from the *.pc files were unsuitable for a very unusual build environment: Using PKG_CHECK_MODULES defines appropriate _CFLAGS and _LIBS variables for the configure script, so even in a very unusual build environments one can always override whatever the *.pc file might contain by calling configure like
../configure ODBC_CFLAGS='-I/weird/stuff -DWEIRD_STRING="moo"' ODBC_LIBS='-L/very/weird/libxyz -lodbc'
So... using odbc_config has no advantages, upstream already provides a odbc.pc file so it is always present, so why not just always use odbc.pc?
So, in configure.ac (if builds without odbc.pc present should fail, otherwise you will have to do some AC_DEFINE and/or AM_CONDITIONAL to conditionally build with or without ODBC support) do
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
PKG_CHECK_MODULES([ODBC], [odbc])
and in any subdirectory (what you call "subproject") Makefile.am or Makefile-files where you need to link somehting against libodbc, put, depending on whether you are building an executable
bin_PROGRAMS += foobar
[…]
foobar_CPPFLAGS += $(ODBC_CFLAGS)
foobar_LDADD += $(ODBC_LIBS)
or a (libtool) library
lib_LTLIBRARIES += libfoo.la
[…]
libfoo_la_CPPFLAGS += $(ODBC_CFLAGS)
libfoo_la_LIBADD += $(ODBC_LIBS)
That should work for all native and cross-compile builds in properly set up build environments, and people can still override odbc_CFLAGS and odbc_LIBS in case of problems.
Of course, you can always AC_CHECK_PROG or AC_PATH_PROG or AC_CHECK_TOOL or AC_PATH_TOOL together with an AC_ARG_VAR for the odbc_config program and then define and AC_SUBST an _CFLAGS and _LIBS variable set to the output of $ODBC_CONFIG --cflags and $ODBC_CONFIG --libs, respectively, and then then use the _CFLAGS and _LIBS vars in Makefile.am/Makefile-files as above.
However, that is a lot of code to write, and with a lot of special cases to consider, and if you have to ask about how to do this you will probably get a lot more wrong than if you just just use PKG_CHECK_MODULES.
You can always add something later if the PKG_CHECK_MODULES route actually does not work for a use case and which cannot be fixed within the pkg-config framework. Until that time (if it ever happens), I would recommend to just use the simple PKG_CHECK_MODULES method and probably be done.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation
Autoconf has AC_PATH_PROG() for checking for a program in the executable search path. You would of course use AC_SUBST() to define one or more output variables by which to convey the results to the generated makefiles.
But no, coming back around to my comment on the answer to one of your previous questions, what you ought to do is not have configure forward information about the executable, but rather for it to determine the needed flags itself and forward them, via one or more output variables. If you continue to use odbc_config, at least conditionally, then that means having configure run it and capture the output. You should not inject shell command substitutions into your compilation commands.
And if you substitute a different mechanism, whether conditionally or exclusively, then similarly for that. (That's what your other answer describes with respect to pkg-config.)

riscv-gcc Fails to build [GCC_NO_EXECUTABLES]

I want to use riscv-gcc to implement an Ibex (RISCV core) example on an Arty-A7 but I haven't been able to build it properly.
It's been failing after the 'make' phase. It seems to have something to do with zlib however I'm not so sure since this is the first time I'm building anything from source. I got the source from https://github.com/riscv/riscv-gcc
I've configure it executed make as
../riscv-gcc/configure --enable-multilib
make
it then exits with the following error
checking whether the gcc -m32 linker (ld -m elf_x86_64 -m elf_i386) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make[2]: *** [configure-stage1-zlib] Error 1
make[2]: Leaving directory `/home/alfred/Desktop/Work/riscv_gcc_install'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/alfred/Desktop/Work/riscv_gcc_install'
make: *** [all] Error 2
I've also tried running make (same configuration) with
make all-gcc
but it produces this error instead
checking if gcc -m32 supports -fno-rtti -fno-exceptions... no
checking for gcc -m32 option to produce PIC... -fPIC -DPIC
checking if gcc -m32 PIC flag -fPIC -DPIC works... yes
checking if gcc -m32 static flag -static works... no
checking if gcc -m32 supports -c -o file.o... yes
checking if gcc -m32 supports -c -o file.o... (cached) yes
checking whether the gcc -m32 linker (ld -m elf_x86_64 -m elf_i386) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
make: *** [configure-zlib] Error 1
I'm not sure what to do so far besides check prerequisite libraries as suggested by https://gcc.gnu.org/install/prerequisites.html . Can Anyone help me out?
[UPDATE 27/11/19]
I tried to install the complete riscv-gnu-toolchain from < https://github.com/riscv/riscv-gnu-toolchain> to avoid missing dependencies however I still had an error. I did run the suggested apt-get command to install the prerequisites.
I ran the configuration suggested to target riscv32 and proceeded with make as follows
./configure --prefix=/opt/riscv --with-arch=rv32gc --with-abi=ilp32d
make linux
I then got this error
make[3]: Entering directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
/bin/bash /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../ylwrap /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/arparse.y y.tab.c arparse.c y.tab.h `echo arparse.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output arparse.output -- bison -y -d
m4: unrecognized option '--gnu'
Try `m4 --help' for more information.
make[4]: Entering directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
/bin/bash /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../ylwrap /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/arparse.y y.tab.c arparse.c y.tab.h `echo arparse.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output arparse.output -- bison -y -d
m4: unrecognized option '--gnu'
Try `m4 --help' for more information.
make[4]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
/bin/bash /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../ylwrap /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.y y.tab.c sysinfo.c y.tab.h `echo sysinfo.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e s/c$/h/` y.output sysinfo.output -- bison -y -d
/home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
m4: unrecognized option '--gnu'
Try `m4 --help' for more information.
if [ -r sysinfo.c ]; then \
gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -I/home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../zlib -g -O2 sysinfo.c ; \
else \
gcc -c -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -I/home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/../zlib -g -O2 /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.c ; \
fi
gcc: error: /home/alfred/Desktop/Work/riscv-gnu-toolchain/riscv-binutils/binutils/sysinfo.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
make[3]: *** [sysinfo.o] Error 4
make[3]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux/binutils'
make[2]: *** [all-binutils] Error 2
make[2]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/alfred/Desktop/Work/riscv-gnu-toolchain/build-binutils-linux'
make: *** [stamps/build-binutils-linux] Error 2
I noticed that m4 did not recognize a certain argument
--gnu
should I be concerned with this?
[UPDATE 16/12/2019]
As recommended, I tried to build the tool-chain in Ubuntu 18.04.03 (originally I was on 14.04) and it seems to have solved the problem quite well! Turns out that the tool-chain is indeed "fragile" when it comes to OS dependencies. Thanks so much for the help!
The error "Link tests are not allowed" is something connected to incomplete toolchain (like ld, binutils, libc), similar to report inhttps://gcc.gnu.org/ml/gcc-help/2012-07/msg00018.html.
It is unclear from your question which instruction did you use to build gcc. I think you should search not for gcc only build, but for complete toolchain instruction like https://github.com/riscv/riscv-gnu-toolchain or something from Ibex authors web-site.
Ibex documentation in page https://ibex-core.readthedocs.io/en/latest/verification.html#getting-started has some link to "GCC setup", but it is for verification and without complete instruction.
In issue https://github.com/riscv/riscv-gcc/issues/143 there is information that "You can't build gcc without binutils." and "You can't build a useful gcc without a C library.", so try to build complete toolchain, not the gcc only.
In earlier project by lowrisc there was instruction to build toolchain (combined gcc + binutils + newlib): https://www.lowrisc.org/blog/2017/09/building-upstream-risc-v-gccbinutilsnewlib-the-quick-and-dirty-way/ - you may want to modify the instruction with another git (riscv-gcc). Or just try https://github.com/riscv/riscv-gnu-toolchain
I have found that the RISC-V toolchain is very fragile with respect to OS dependencies. The toolchain team uses Ubuntu 16, and a lot of errors folks see arise from the changes to the Linux ecosystem since that version.
I got around this issue by creating a Vagrantfile that is configured to use Ubuntu 16, and goes through the official steps, and at least for me, it builds the tools just fine. If you're interested, it's posted inside the stackoverflow question I asked along these lines. If you need to configure the tools differently, it's straightforward to do in the Vagrantfile.
Try this version for integer riscv. I tried it already and passed.
git clone https://github.com/riscv/riscv-gnu-toolchain
git checkout 411d134
git submodule update --init --recursive
mkdir build
cd build
../configure --prefix=/opt/riscv32i --with-arch=rv32i --with-abi=ilp32
make -j8
If your riscv has mul/div module, add M standard extension.
../configure --prefix=/opt/riscv32im --with-arch=rv32im --with-abi=ilp32
If your riscv is 64-bit integer core:
../configure --prefix=/opt/riscv64i --with-arch=riscv64i --with-abi=lp64
select option that you want to build:
"M" Standard Extension for Integer Multiplication and Divison
"A" Standard Extension for Atomic Instructions
"F" Standard Extension for Single-Precision Floating-Point
"D" Standard Extension for Double-Precision Floating-Point
"Q" Standard Extension for Quard-Precision Floating-point
"C" Standard Extension for Compressed Instruction
"G" combination of I, M, A, F and D.
ilp32/ilp32f/ilp32d int-32bits long-32bits pointer-32bits
lp64/lp64f/lp64d int-32bits long-64bits pointer-64bits
The vexrisc full project implement riscv on arty a7 35t, includes toolchain compile and using IntelliJ IDE build riscv project and internal USB jtag debugging may help you.
https://fatalfeel.blogspot.com/2013/12/risc-v-on-arty-a7-35t.html
Maybe you want to try Linux on riscv. It's based on vexrisc
https://github.com/SpinalHDL/SaxonSoc

Homebrew libtool installation stuck at `rm -rf`

libtool won't install on my mac via Homebrew nor MacPorts (needed for RVM).
This is the verbose output where it hangs forever, running OS X 10.9 & Xcode 4.3
libtool: link: ( cd "libltdl/.libs" && rm -f "dlopen.la" && ln -s "../dlopen.la" "dlopen.la" )
/bin/sh ./libtool --tag=CC --mode=link cc -g -O2 -no-undefined -version-info 10:0:3 -dlpreopen libltdl/dlopen.la -o libltdl/libltdl.la -rpath /usr/local/Cellar/libtool/2.4.2/lib libltdl/loaders/libltdl_libltdl_la-preopen.lo libltdl/libltdl_libltdl_la-lt__alloc.lo libltdl/libltdl_libltdl_la-lt_dlloader.lo libltdl/libltdl_libltdl_la-lt_error.lo libltdl/libltdl_libltdl_la-ltdl.lo libltdl/libltdl_libltdl_la-slist.lo libltdl/argz.lo
libtool: link: rm -f libltdl/.libs/libltdl.nm libltdl/.libs/libltdl.nmS libltdl/.libs/libltdl.nmT
libtool: link: (cd libltdl/.libs && cc -g -O2 -c -fno-builtin -fno-rtti -fno-exceptions -fno-common -DPIC "libltdlS.c")
brew: superenv removed: -g -O2
libtool: link: rm -f "libltdl/.libs/libltdlS.c" "libltdl/.libs/libltdl.nm" "libltdl/.libs/libltdl.nmS" "libltdl/.libs/libltdl.nmT"
Any ideas?
I has the same issue, did a bit of tracing and found that is was actually stuck waiting for output to be grepped from the "lipo" command.
Looked around a bit and found the following solution: replace
/usr/bin/lipo
with the one under
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin
and the compilation will work. You need the development environment to be installed.
MrWHO
Rather than replace your system files, most configure scripts will take accept taking lipo as a env variable:
export LIPO=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/lipo
./configure
make
None of the other solutions worked for me, and, admittedly, my error message wasn't identical but did contain a rm -rf, so to whomever this might help:
What got rid of this error for me was adding this line immediately before the call to make (well gmake really in my case):
ENV.deparallelize
What led me to this was noticing that there was another line in the log output with exactly the same content, but which succeeded, so I reckoned this might be a timing/ordering issue, so ENV.deparallelize was the first thing to try.
P.S. If anyone could shed light onto why parallelization inside make might be causing this, I'd appreciate that — non-parallel make is so much slower!
UPDATE: adding env :std solved the issue for me without requiring ENV.deparallelize; thanks to ilovezfs on #machomebrew for the hint!

How to run "gmake install"?

I am now installing a code on my mac.
The code is from here. Look for "Benchmark and Boundary Detection Code" in this page.
In the readme file, it says:
(1) For the image and segmentation reading routines in the Dataset
directory to work, make sure you edit Dataset/bsdsRoot.m to point to
your local copy of the BSDS dataset.
(2) Run 'gmake install' from this directory to build everything. You
should then probably put the lib/matlab directory in your MATLAB path.
(3) Read the Benchmark/README file.
For the 1st step, I did as suggested.
For the 2nd step, I am pretty confused. I ran command gmake install in MATLAB, however, I got:
gmake
Undefined function or variable 'gmake'.
Actually, before running MATLAB, I installed gmake port through macports.
I just did it in terminal, however, this is what I got...
hou229:segbench yaozhongsong$ cd /Users/yaozhongsong/Documents/MATLAB/segbench
hou229:segbench yaozhongsong$ sudo gmake install
gmake[1]: execvp: ../Util/gethosttype: Permission denied
gmake[1]: Entering directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
GNUmakefile-library:26: *** mexSuffix not defined. Stop.
gmake[1]: Leaving directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
hou229:segbench yaozhongsong$
In MATLAB, I also did like this:
!gmake install
/bin/bash: gmake: command not found
How to do the 2nd step in readme file?
Thanks in advance!
#Amro
hou229:segbench yaozhongsong$ cd /Users/yaozhongsong/Documents/MATLAB/segbench
hou229:segbench yaozhongsong$ sudo gmake install
Password:
gmake[1]: execvp: ../Util/gethosttype: Permission denied
gmake[1]: Entering directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
mkdir -p ../lib/matlab
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Exception.cc -o build//Exception.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c String.cc -o build//String.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Random.cc -o build//Random.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Timer.cc -o build//Timer.o
g++ -g -Wall -fPIC -I../include -O3 -DNOBLAS -c Matrix.cc -o build//Matrix.o
Matrix.cc:13:21: error: ieee754.h: No such file or directory
Matrix.cc: In function ‘double nextpow2(double)’:
Matrix.cc:86: error: ‘ieee754_double’ was not declared in this scope
Matrix.cc:86: error: expected `;' before ‘val’
Matrix.cc:87: error: ‘val’ was not declared in this scope
Matrix.cc:88: error: ‘IEEE754_DOUBLE_BIAS’ was not declared in this scope
Matrix.cc: At global scope:
Matrix.cc:48: warning: ‘snan’ defined but not used
Matrix.cc:49: warning: ‘inf’ defined but not used
gmake[1]: *** [build//Matrix.o] Error 1
gmake[1]: Leaving directory `/Users/yaozhongsong/Documents/MATLAB/segbench/Util'
For the "mexSuffix not defined" error, first run mexext inside MATLAB, take that output (I suspect it is mexmaci64), edit the file Util/GNUmakefile-library and add the following at line 24:
mexSuffix := mexmaci64
replace the value with the one you get from mexext
Note: I haven't tested any of this, I am on a Windows machine..
You need to run gmake from the Terminal (command line), not in MATLAB.

make library not found

I'm trying to compile a program using a third party library, Omnet++ in my case. Apparently "make" does not find a library, but the path it uses is correct as you can see (in the sense that I can see the library under omnet++ source tree)
pv135168:basic Bob$ opp_makemake
Creating Makefile in /Users/Bob/Code/network_sim/basic... Makefile created, running "make depend" to add dependencies... opp_makedep -Y --objdirtree -I. -f Makefile -P\$O/ -- ./*.cc
pv135168:basic Bob$ make
g++ -c -g -Wall
-fno-stack-protector -m32 -DHAVE_PCAP -DXMLPARSER=libxml
-DWITH_PARSIM -DWITH_NETBUILDER -I.
-I/Users/Bob/Code/omnetpp-4.1/include -o out/gcc-debug//txc1.o txc1.cc g++ -m32 -Wl,-rpath,/Users/Bob/Code/omnetpp-4.1/lib -Wl,-rpath,. -o out/gcc-debug//basic out/gcc-debug//txc1.o -Wl,-all_load
-L"/Users/Bob/Code/omnetpp-4.1/lib/gcc"
-L"/Users/Bob/Code/omnetpp-4.1/lib" -u _tkenv_lib -lopptkenvd
-loppenvird -lopplayoutd -u _cmdenv_lib -loppcmdenvd -loppenvird
-loppsimd -lstdc++
ld: library not found for -lopptkenvd
collect2: ld returned 1 exit status make: *** [out/gcc-debug//basic]
Error 1 pv135168:basic Bob$
It's looking in the following directories for a file called libopptkenvd.dylib or libopptkenvd.a:
/Users/Bob/Code/omnetpp-4.1/lib/gcc
/Users/Bob/Code/omnetpp-4.1/lib
Is that file in one of those directories (or in the standard directories like /usr/lib)? I don't see an indication of that in your output.

Resources