Re: Automake mingw cross compile problems
Stefano Lattarini wrote: Which compiler(s) are you using exactly? i686-w64-mingw32, compiled from source. The compiler is the same one that was working correctly just recently. Which version(s)? gcc version 4.5.0 20100329 (experimental) (GCC) More importantly, which version of libtool are you using? libtool 2.4 Have you changed that too recently? Possibly. I think I was using 2.2.6 some time recently. I've tried downgrading libtool the 2.2.6b (Debian package), but that results in a huge number of warnings from autoconf. And reading the above, I suspect it *might* be a libtool bug. Looking at this more closely, I tend to agree. I'll take this to the libtool list. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Re: Automake mingw cross compile problems
Erik de Castro Lopo wrote: The problem is that the test programs don't get built. Or rather something gets built and put in the G72x/.libs directory, but there is nothing in the G72x/ directory for the generated Makefile to run. Just as an addendum to this bug report, the G72x/.libs/ directory also contains a file named g72x_test_ltshwrapper. This file is a bash script, but is not executable. However, running it as: bash G72x/.libs/g72x_test_ltshwrapper results in the error: G72x/.libs/g72x_test_ltshwrapper: error: `/home/erik/test/src/G72x/.libs/.libs/g72x_test.exe' does not exist suggesting that the script was actually meant for one directory above where it ended up. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Automake mingw cross compile problems
Hi all, I all I have a rather large Makefile.am that used to work for both native compiles on linux and cross compiles from linux to windows. This suddenly stopped working with automake 1.11.1 from debian. The relevant parts of the Makefile.am are: AUTOMAKE_OPTIONS = subdir-objects noinst_PROGRAMS = test_main$(EXEEXT) G72x/g72x_test$(EXEEXT) noinst_LTLIBRARIES = GSM610/libgsm.la G72x_g72x_test_SOURCES = G72x/g72x_test.c G72x_g72x_test_LDADD = G72x/libg72x.la check : $(noinst_PROGRAMS) G72x/g72x_test$(EXEEXT) all ./test_main$(EXEEXT) The problem is that the test programs don't get built. Or rather something gets built and put in the G72x/.libs directory, but there is nothing in the G72x/ directory for the generated Makefile to run. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Silencing doxygen output
Hi all, I'm using AM_SILENT_RULES([yes]) to silence make output and I'm pretty happy with it. However, I have a doxygen command in a Makefile.am: doxygen reference.doxygen and I can't figure out how to silence it. Clues? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/
Re: yacc/lex name conflicts
Christian Csar wrote:
Is there anyway to control the behavior of ylwrap? The project I am
converting has its parsers use files like foo.l and foo.y for the lex
and yacc files as they go together, and automake then converts both of
these to foo.c, overwriting the first seemingly silently. Admittedly I
solved this by changing foo.l to foo-lex.l, but it seems rather
inelegant. If there is a to notice the existence of foo.l and foo.y in
the same directory, it might be worth printing out a message as it is
not an immediately obvious problem (except for refusing to build).
Is these old school lex/yacc or are you actually using flex/bison?
The reason I ask is that flex/bison allow renaming all the generated
symbols and I'm not sure if lex/yacc support this.
For flex, you add something like this at the top of the file:
%option prefix = my_
and for bison you add this:
%name-prefix = my_
after the first '%{' '%}' block.
HTH,
Erik
--
-
Erik de Castro Lopo
-
Question #70427: Sitting beside women on public transport because
one is forced to
http://islamqa.com/index.php?ln=engds=qalv=browseQR=70427dgn=4
Re: Mixing C and C++?
Ralf Wildenhues wrote: Please post a small example package that exposes this, or, if that's too much work, the configure.ac and tests/Makefile.am files; and state which program versions you use. Trying to set up a test showed up an even bigger problem. I'm using: automake (GNU automake) 1.9.6 autoconf (GNU Autoconf) 2.61 ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-1ubuntu1 (1.1220.2.493 2008/02/01 16:58:18) installed from packages on an Hardy Heron machine. The test project is here: http://www.mega-nerd.com/tmp/amtest-0.1.tar.gz If I extract these sources and do: ./autogen.sh (which also runs configure) make it results in the following error: if gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -MT amtest.o -MD -MP \ -MF .deps/amtest.Tpo -c -o amtest.o amtest.c; \ then mv -f .deps/amtest.Tpo .deps/amtest.Po; else rm -f \ .deps/amtest.Tpo; exit 1; fi /bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -o amtest amtest.o mkdir .libs gcc -g -O2 -o amtest amtest.o amtest.o: In function `main': /tmp/amtest-0.1/amtest.c:10: undefined reference to `cpp_test' For some reason, the automake generated Makefile drops the C++ object file from the link. What am I doing wrong here? Cheers, Erik -- - Erik de Castro Lopo - Two hands working can do more than a thousand clasped in prayer. -- anonymous
Re: Mixing C and C++?
Olly Betts wrote: You'd written test_sources = ... which has no special meaning to automake. You should have written amtest_SOURCES = In the absence of amtest_SOURCES, automake implicitly assumes amtest_SOURCES = amtest.c. Yes, thats what I'd done in the small test project I had created. I did not make the same mistake in the main project. That one remains a bit of a mystery. Cheers, Erik -- - Erik de Castro Lopo - ... a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god. -- Thant Tessman
Re: Mixing C and C++?
Ralf Wildenhues wrote: Hmm, can you relate the main project to us? Have you tried automake -Wall? Its my main project libsndfile. I fixed it somehow and can't remember how to get it back into the state where I reported the bug. Sorry :-) Cheers, Erik -- - Erik de Castro Lopo - If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargill
Re: Cross compiling with pkg.m4
John Darrington wrote: pkg.m4 doesn't behave in a very rational way, when configured with --host=xyzzy I successfull use pkg-config when compiling from Linux to windows using: ./configure --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux My i586-mingw32msvc-pkg-config is documented here: http://www.mega-nerd.com/erikd/Blog/CodeHacking/MinGWCross/pkg-config.html Erik -- - Erik de Castro Lopo - We can build a better product than Linux -- Microsoft Corp.'s Windows operating-system chief, Jim Allchin. One has to wonder why, with their huge resources, they haven't.
Re: Makefile.am for both windows and linux
Nitin Goyal wrote:
Hi,
How can I make use of variables in Makefile.am for automake primaries? I
want to write Makefile.am as
lib_LIBRARIES = $(PREFIX)mylib.$(LIBSUFFIX)
libdir = ${prefix}/lib
$(PREFIX)_mylib_$(LIBSUFFIX)_SOURCES = mylib.c
I can not use libtools. Is there a way, I can achieve this?
I use autoconf/automake/libtool on two projects that compile quite
happily on Unix and windows (MinGW).
Erik
--
-
Erik de Castro Lopo
-
We respect the right of everyone to believe whatever they like.
But there are two important limits to religious tolerance. First, I have no
right to legal protection against your scepticism, criticism or ridicule.
Religion is too powerful a force, and is too often a cause of injustice or
evil, for it to be immune from discussion and debate.
-- David Pannick QC
http://www.timesonline.co.uk/tol/life_and_style/career_and_jobs/legal/article729808.ece
Re: substitution vs expansion in Makefile.am
Harlan Stenn wrote: You can use: ../common/mySleep.c in your foo_SOURCES list. If the sources are in /home/user/src and you go to /home/usr/build and do ../src/configure the above will be completely wrong. The correct way to do it is to use $(top_srcdir)/common/mySleep.c which will work under all circumstances. Erik -- - Erik de Castro Lopo - The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. -- Paul Graham
Modifying CFLAGS for 'make distcheck'
Hi all, I am a big fan of 'make distcheck' and also a fan of compiling with gcc's -Werrror flag. Most of my configure.ac scripts also have a --enable-gcc-werror options so that I can use -Werror while developing but ship tarballs without it. So now I had this great idea. Wouldn't it be great if I could tell 'make distcheck' use './configure --enable-gcc-werror'! Anyone have a clue on how to do this? Cheers, Erik -- - Erik de Castro Lopo - Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. - John Von Neumann (1951)
Re: Modifying CFLAGS for 'make distcheck'
Braden McDaniel wrote: Anyone have a clue on how to do this? DISTCHECK_CONFIGURE_FLAGS = --enable-gcc-werror in your top-level Makefile.am. Wow, that is a very beautiful thing. Thanks Braden! Cheers, Erik -- - Erik de Castro Lopo - This is like creating laws against blasphemy and then complaining that unbelievers can't come up with any logical argument against the existence of God -- www.infoanarchy.org on the Digital Millenium Copyright Act
