automake links my C programs with the C++ compiler
Hi, Some of the gettext programs contain or don't contain C++ source code, depending on the platform and configure options. Automake-1.9.6 and -1.9b emit rules to always link the programs with the C++ compiler. For automake-1.9.6 this was easy to work around: # Linking with C++ libraries is needed _only_ on mingw and Cygwin. if !WOE32DLL CXXLINK = $(LINK) endif Now, in automake-1.9b, thanks to this announced change: Per-target flags are now correctly handled in link rules. the workaround becomes much more complex: I would have to override all of the following variables: libgettextsrc_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(libgettextsrc_la_LDFLAGS) $(LDFLAGS) -o $@ msgattrib_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(msgattrib_LDFLAGS) $(LDFLAGS) -o $@ msgcat_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \ $(msgcat_LDFLAGS) $(LDFLAGS) -o $@ msgcomm_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \ $(msgcomm_LDFLAGS) $(LDFLAGS) -o $@ msgconv_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \ $(msgconv_LDFLAGS) $(LDFLAGS) -o $@ msgen_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \ $(msgen_LDFLAGS) $(LDFLAGS) -o $@ msgfilter_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(msgfilter_LDFLAGS) $(LDFLAGS) -o $@ msggrep_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) \ $(msggrep_LDFLAGS) $(LDFLAGS) -o $@ msgmerge_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(msgmerge_LDFLAGS) $(LDFLAGS) -o $@ xgettext_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \ $(CXXFLAGS) $(xgettext_LDFLAGS) $(LDFLAGS) -o $@ So, can you please do something about the original problem? Here is a testcase. === Makefile.am = AUTOMAKE_OPTIONS = 1.5 foreign lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo1.c if WOE32DLL libfoo_la_SOURCES += foo2.cc endif bin_PROGRAMS = msgfmt msgmerge if WOE32DLL msgfmt_SOURCES = c++msgfmt.cc else msgfmt_SOURCES = msgfmt.c endif if WOE32DLL msgmerge_SOURCES = c++msgmerge.cc else msgmerge_SOURCES = msgmerget.c endif msgfmt_CPPFLAGS = -DPROG=\msgfmt\ msgmerge_CPPFLAGS = -DPROG=\msgmerge\ msgfmt_LDFLAGS = -lfoo msgmerge_LDFLAGS = -lfoo === configure.ac = AC_INIT AC_CONFIG_SRCDIR(foo1.c) AC_CONFIG_AUX_DIR(.) AM_INIT_AUTOMAKE(foo, 0.0) AM_CONFIG_HEADER(config.h) AC_PROG_CC AC_PROG_CXX AC_LIBTOOL_WIN32_DLL AC_PROG_LIBTOOL if test $enable_shared = yes; then case $host_os in mingw* | cygwin*) is_woe32dll=yes ;; *) is_woe32dll=no ;; esac else is_woe32dll=no fi AM_CONDITIONAL([WOE32DLL], [test $is_woe32dll = yes]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT == $ mkdir m4 $ cp .../libtool-1.5.22/m4/libtool.m4 m4/libtool.m4 $ cp .../libtool-1.5.22/ltmain.sh ltmain.sh $ aclocal -I m4 $ autoconf $ autoheader $ automake -a -c You can see that in the generated file - The libfoo.la rule always uses the $(CXXLINK) variable, - The msgfmt$(EXEEXT), msgmerge$(EXEEXT) rules always use the $(msgfmt_LINK) resp. $(msgmerge_LINK) variables, and these are always defined to a value starting with $(LIBTOOL) --tag=CXX ... Can you change this to a conditional definition of these rules and variables, matching the WOE32DLL condition in the Makefile.am and using --tag=CC when no C++ source file is involved? If this is not possible before automake-1.10: Can you refactor the common part of these *_LINK variables, namely $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) into a single variable, that I could override? Bruno
Can't find the correct set of libs on FC5/x64
I'm currently taking a course in graphics programming with OpenGL, and
thought it would be kind of me to turn in assignments which are
./configurable. My desktop environment is an OS X box, and the TAs are
running a variety of different Unices.
This seems like a job for Autotools, so I set up a minimal environment.
I'm not an Autotools geek by any stretch of the imagination, but
getting it running under OS X involved not very much pain at all.
However, it bombs under Fedora Core 5 on x64. Apparently it finds
different libraries (both 64-bit and 32-bit) and tries to use both sets
simultaneously for linking purposes, which is causing no end of heartbreak.
The minimal environment is set up as:
template/ --+
|
+ src/
The template/configure.in:
AC_INIT(src/test.cpp)
AC_CONFIG_HEADERS(config.h)
AM_INIT_AUTOMAKE(rjh-hwk, 1.0)
AC_PROG_CC
AC_PROG_CXX
AC_PROG_LIBTOOL
AX_BOOST([1.32.0],[],[AC_MSG_ERROR([Package requires the Boost
libraries.])])
AX_CHECK_GL
AC_OUTPUT(Makefile src/Makefile)
The template/Makefile.am:
SUBDIRS=src
The template/src/Makefile.am:
AM_CFLAGS=${CFLAGS} ${PTHREAD_CFLAGS} ${GL_CFLAGS}
AM_CPPFLAGS=${CPPFLAGS} ${PTHREAD_CFLAGS} ${GL_CFLAGS} ${BOOST_CPPFLAGS}
LIBS=${BOOST_LIBS_R} ${GL_LIBS}
CC=${PTHREAD_CC}
bin_PROGRAMS=hwk_1
hwk_1_SOURCES = test.cpp
And, finally, the error I'm seeing:
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o hwk_1 test.o
-lGL -L/usr/X11R6/lib64 -lX11
g++ -g -O2 -o hwk_1 test.o /usr/lib/libGL.so -L/usr/X11R6/lib -lm
-lXext -ldl -L/usr/X11R6/lib64 -lX11
/usr/lib/libGL.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [hwk_1] Error 1
make[2]: Leaving directory
`/mnt/nfs/fileserv/grad/rjhansen/Projects/22c151/template/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/mnt/nfs/fileserv/grad/rjhansen/Projects/22c151/template'
make: *** [all] Error 2
... Can anyone give me a simple Autotools solution to these build woes?
Also, if there are any style pointers on how to make this setup more
canonically correct (while still being readable to a non-wizard), I'd
welcome any corrections.
Thanks much for any help you can provide.
distdir unset in subdir Makefiles?
Hi, I've noticed that the distdir variable in generated Makefile.in's only appears in the top-level Makefile.in, however, it is not set in subdirectories' Makefile.in's. Is this intentional? According to the top Makefile.in, distdir and top_distdir are passed down recursively during a make distdir, set to $(PACKAGE)-$(VERSION) and subdirs. In one instance, I wished to manually inspect the result of one of the subdirectories' make distdir, but had to pass in these two variables by hand, slightly inconvenient. Is there a rationale for omitting these two variables in subdir's Makefile.in's? Thanks in advance. Fang
differences between gmake and freebsd's make
I've got a project that uses automake-1.9.6. I run autoreconf. I go to a FreeBSD machine, create a subdir for the build, cd there, and run ../configure. I run 'gmake' and everything builds. I run 'gmake' again and the beast completes without building anything (no surprise). I run 'make' and things get built. I understand this is a vague report. Before I get down and dirty to figure out exactly what files/dependencies are causing this, does this ring any bells for anybody and has this been discussed/evaluated before? H
Re: differences between gmake and freebsd's make
Hello Harlan, * Harlan Stenn wrote on Fri, Aug 25, 2006 at 03:07:52AM CEST: I run 'gmake' and everything builds. I run 'gmake' again and the beast completes without building anything (no surprise). I run 'make' and things get built. Yes, this rings two bells, a general and a more specific one: http://www.gnu.org/software/autoconf/manual/html_node/Portable-Make.html http://www.gnu.org/software/autoconf/manual/html_node/Make-Target-Lookup.html I'd first try doing a non-VPATH build and see whether that works. Cheers, Ralf
Re: differences between gmake and freebsd's make
Thanks, Ralf! I also am seeing a problem with /usr/ccs/bin/make on solaris. I do suspect a VPATH thing at the moment. It is very strange to me that it only happens in some directories and not in others. I'm digging... H -- Hello Harlan, * Harlan Stenn wrote on Fri, Aug 25, 2006 at 03:07:52AM CEST: I run 'gmake' and everything builds. I run 'gmake' again and the beast completes without building anything (no surprise). I run 'make' and things get built. Yes, this rings two bells, a general and a more specific one: http://www.gnu.org/software/autoconf/manual/html_node/Portable-Make.html http://www.gnu.org/software/autoconf/manual/html_node/Make-Target-Lookup.html I'd first try doing a non-VPATH build and see whether that works. Cheers, Ralf
