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!
Related
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.)
I am trying to install tabix and I've already install command lines for Xcode on my Mac. However, when I run 'make' they response like this and the result that I've still finish installing.
gcc -g -Wall -O2 -fPIC -o tabix main.o -L. -ltabix -lm -lz
I'm just quite new on MacOS and terminal. So, thanks if you have any advices for me.
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.
I have a master Makefile that calls submakefiles inside directories.
Those submakefiles are generated by autotools starting from Makefile.am and configure.ac files.
The first target of the entire project is a shared library, while the others are executables that link against it (so there is a dependency in the main Makefile).
The problem is that I can only see the compilation output of the shared library, while the other projects are just printing warnings and errors (just stderr text, I believe).
I can't understand what is causing this behaviour since all the projects are called from the very same rule in the master Makefile and all the submakefiles are autogenerated from very seemed configuration files.
The snippet of master Makefile that compiles all the targets looks like this:
SUBDIRS = libMylib app1 app2 app3
$(SUBDIRS):
$(ECHO) "-> Building $#"
$(MAKE) -C $#
$(ECHO) "-> Build of $# finished."
The output of "libMylib" is like:
-> Building libMylib
libtool: compile: ppc-linux-gcc -DHAVE_CONFIG_H -I. -I/opt/ELDK/ppc_8xx/usr/include/ -I/opt/ELDK/ppc_8xx/include/ -Wall -std=gnu99 -O2 -MT libMylibF1.lo -MD -MP -MF .deps/libMylibF1.Tpo -c libMylibF1.c -fPIC -DPIC -o .libs/libMylibF1.o
...
libtool: link: ppc-linux-gcc -shared -fPIC -DPIC .libs/libMylibF1.o .libs/libMylibF2.o .libs/libMylibF3.o -Wl,-rpath -Wl,/opt/ELDK/ppc_8xx/lib -Wl,-rpath -Wl,/opt/ELDK/ppc_8xx/lib -lz -lpthread -O2 -Wl,-soname -Wl,libMylib.so.0 -o .libs/libMylib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libMylib.so.0" && ln -s "libMylib.so.0.0.0" "libawmg.so.0")
libtool: link: (cd ".libs" && rm -f "libMylib.so" && ln -s "libMylib.so.0.0.0" "libMylib.so")
libtool: link: ( cd ".libs" && rm -f "libMylib.la" && ln -s "../libMylib.la" "libMylib.la" )
-> Build of libAwmg finished.
While the output of any "appN" is:
-> Building app1
app1F1.c: In function `app1F1Func1':
app1F1.c:161: warning: unused variable `varA'
app1F2.c:85: warning: `app1F2FuncX' defined but not used
-> Build of app1 finished.
Could anyone please help me?
EDIT:
I found out that I was able to see the compile stuff in "libMylib" because it is "libtoolized".
If I "libtoolize" another project, I can see the linker part of the output (libtool: link:...).
So, considering that make calls a shell (sh) for each line in the rule, that $(MAKE) equals to just "make" and, by default, make is verbose, why do the submake is not printing its output to stdout?
Which flags may be passed to it so that this happens?
It depends on the Makefiles in the sub directories. If, for example, you have a # in front of the compile commands in the app Makefiles, then they will not output the commands that were being run (also look for $(Q), which is used quite commonly when you want to enable/disable verboseness in makefiles). Alternatively, your make commands in the apps directories may be pushing stdout to some files (which would still allow you to see the warnings).
By the same token your library makefile may be incorrectly redirecting stderr elsewhere, which would explain why you don't see any error outputs on that (or it just doens't have any errors...)
Please post the build rules in the other directories (and all associated variable definitions) if you want more help.
Well, my master makefile includes another file that puts a .SILENT rule in.
I haven't noticed that until today.
Removing this rule makes everithing work as expected.
Oh my...
I use a custom build tool to compile go projects and I need a way to use cgo in my project.
The problem is that the cgo documentation only tells you how to use it with make.
What I really need to know is which generated files to process with which tools and in what order it needs to be done. I tried to read make.pkg in the go source dir but my best effort fails.
My test dll is very simple, a single function that returns 1 every time it is called and the go code to use this function is similarly simple.
The output from the console produced by a successful run of make on a cgo project would be very helpful.
Output of running make on 32-bit Linux in directory misc/cgo/life:
# gomake _obj/life.a
CGOPKGPATH= cgo -- life.go
touch _obj/_cgo_run
8g -o _go_.8 _obj/life.cgo1.go _obj/_cgo_gotypes.go
8c -FVw -I ${GOROOT}/pkg/linux_386 -I . -o "_cgo_defun.8" _obj/_cgo_defun.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_main.o -c _obj/_cgo_main.c
gcc -m32 -g -fPIC -O2 -o c-life.o -c c-life.c
gcc -m32 -I . -g -fPIC -O2 -o life.cgo2.o -c _obj/life.cgo2.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_export.o -c _obj/_cgo_export.c
gcc -m32 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o c-life.o life.cgo2.o _cgo_export.o
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_ _obj/_cgo_import.c
8c -FVw -I . -o "_cgo_import.8" _obj/_cgo_import.c
rm -f _obj/life.a
gopack grc _obj/life.a _go_.8 _cgo_defun.8 _cgo_import.8 c-life.o life.cgo2.o _cgo_export.o
The line cgo -- life.go creates the following files:
_obj/_cgo_.o
_obj/life.cgo1.go
_obj/life.cgo2.c
_obj/_cgo_gotypes.go
_obj/_cgo_defun.c
_obj/_cgo_main.c
_obj/_cgo_flags
_obj/_cgo_export.c
_cgo_export.h
"I use a custom build tool to compile go projects and I need a way to use cgo in my project."
... and this approach leads to problems. Using the standard way with a Makefile is simple, easy, proven, documented, etc.
I realize I'm not (directly) answering your question. Instead my "answer" is: I strongly suggest to use the standard way. Don't create problems for your self by choosing other, not directly supported options.
That said, I think there is a way to avoid the Makefiles, I just never been there, sorry. I'm usually lazy/short of time, so I use the simplest/fastest way to get things done. You might want to try the same ;-)