Re: split check target into check and test targets
On Wed, Feb 24, 2010 at 7:17 PM, John Calcote john.calc...@gmail.com wrote: Alexander's solution is great, though. I'm going to use that one myself. For this, you'd need to change all Makefile.ams and it isn't working recursively... What is with having AC_SUBST(TESTS) in configure.in and running: $ make check TESTS= to skip test execution? Additionally, if I want to build a particular check program (perhaps as I'm working out the compiler errors, but before I'm ready to actually run the tests), I just type make check-program-name from that directory. You just have to remember to add `.exe' on cygwin and MSYS, especially within scripts / make rules ($(EXEEXT)), otherwise (at least GNU-) make uses a default built-in rule to compile and link check-program-name, typically with different LIBS. The compiler command line looks plausible but fails and confuses people :-) oki, Steffen
Re: Problem of: variable `main_SOURCES' is defined but no program or library has `main' as canonical name (possible typo)
bin_PROGRA*M*S = main ahh great, so it caught the typo :-) oki, Steffen
Multiplatform autotools; all OK on Linux, warning on Windows
Hi, I am not really sure that this a question for this list but maybe there is a kind sole that has the answer over here I have a Autools based project that I *really* want to compile both on Linux and Windows using gcc (mingw on Windows) using Autotools. I get these warnings: *** Warning: linker path does not have real file for library -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libpthread and none of the candidates passed a file format test *** using a file magic. Last file checked: /home/jkr/src/mingw-cross-env-2.10/usr/lib/gcc/i686-pc-mingw32/4.4.0/../../../../i686-pc-mingw32/lib//libpthread.a *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. Are these warning something I should/can fix? What is it they are trying to tell me? If they are fixable, how? TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl
Re: split check target into check and test targets
Hello, * Steffen Dettmer wrote on Tue, Mar 02, 2010 at 11:00:39AM CET: On Wed, Feb 24, 2010 at 7:17 PM, John Calcote wrote: Alexander's solution is great, though. I'm going to use that one myself. For this, you'd need to change all Makefile.ams and it isn't working recursively... Yes. What is with having AC_SUBST(TESTS) in configure.in and running: $ make check TESTS= to skip test execution? I don't see why you need the AC_SUBST in order to be able to do the second line. In fact, it is typically harmful because when not used, automake mangles the TESTS variable nicely for you, adding $(EXEEXT) where needed and so on. You have to do that yourself in configure. Additionally, if I want to build a particular check program (perhaps as I'm working out the compiler errors, but before I'm ready to actually run the tests), I just type make check-program-name from that directory. You just have to remember to add `.exe' on cygwin and MSYS, especially within scripts / make rules ($(EXEEXT)), otherwise (at least GNU-) make uses a default built-in rule to compile and link check-program-name, typically with different LIBS. The compiler command line looks plausible but fails and confuses people :-) That, too. Cheers, Ralf
Re: Public header files
On 01/03/10 19:35, Ralf Wildenhues wrote: Hello Jef, * Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET: How do I get information generated by autotools into my public header files? For instance I want to define version numbers somewhere in my configure.ac file, and have the same numbers appear in a public header file without having to modify both files manually? Another example is that my library needs a 64bit integer type for its public api. Since a config.h header files is not supposed to be public, that's not an option. But how can I do this correctly? Use a second config header. Its input template will not be generated by autoheader; you write it yourself. That way you can be sure to only put safe stuff in there. Can you give me some info to guide me into the right direction. I don't know where or what I should be looking for. As much as possible, try to think of the possibility that your users may enable or disable presence of a 64bit integer with compiler command line options they pass to their package's configure script, or want a multilib-like installation, where they adjust --libdir for different ABI versions of your package; you should strive to have as few variation in public headers as possible, ideally both versions install the same header files (and only differ in semantics through preprocessor means). For the 64bit integer, I am using the preprocessor right now: #ifdef _WIN32 typedef __int64 ticks_t; #else typedef long long int ticks_t; #endif It works fine for every system I have access too, but long long is not standard and thus not guaranteed to be present. So I just want to make sure it will work on other systems too. An alternative of the above approach is the AX_PREFIX_CONFIG_H macro from the Autoconf Macro Archive. I'll have a look at that too.
Re: Public header files
* Jef Driesen wrote on Tue, Mar 02, 2010 at 10:03:35PM CET: On 01/03/10 19:35, Ralf Wildenhues wrote: * Jef Driesen wrote on Mon, Mar 01, 2010 at 01:33:46PM CET: Since a config.h header files is not supposed to be public, that's not an option. But how can I do this correctly? Use a second config header. Its input template will not be generated by autoheader; you write it yourself. That way you can be sure to only put safe stuff in there. Can you give me some info to guide me into the right direction. I don't know where or what I should be looking for. Hmm, put AC_CONFIG_HEADERS([config.h foo-api.h]) ... AC_DEFINE([ticks_t], [...], [...]) in configure.ac, create foo-api.h.in with contents /* Public API header of package Foo */ ... #undef ticks_t and add foo-api.h to include_HEADERS in Makefile.am. Untested, be sure to test distcheck. Cheers, Ralf
Re: cross-compiling on 64 to 32-bit Linuxlocalhost/
You need a bi-arch system, that is, one that has the system libraries both in a 64-bit variant and in a 32-bit variant (typically in /lib64 and /lib, respectively). For compiling in 32-bit mode, I use ./configure --host=i686-pc-linux-gnu \ --prefix=/arch/x86-linux/gnu \ CC=gcc -m32 -march=i586 \ CXX=g++ -m32 -march=i586 \ LDFLAGS=-m32 Hello, I'm curious about why setting --host=i686-pc-linux-gnu is not enough to achieve cross compiling and why in that case it's not up to autoconf to add -m32 to CC. I know the autoconf manual says you're better of using CC=gcc -m32 or CC=gcc -m64 (see http://www.gnu.org/software/autoconf/manual/autoconf.html#index-CFLAGS-79 ). But somehow, it feels weird to write CC=gcc -m32 when one purpose of autoconf is actually to select a compiler for you. Isn't there another way around CC=gcc -m32 or CFLAGS=-m32? Or are -m32 and -m64 peculiarities of GCC only? Regards, Gregory
Re: distcheck and canonical_*
On Fri, Feb 26, 2010 at 2:55 PM, NightStrike nightstr...@gmail.com wrote: When doing a make distcheck, why is for instance the --host option not propagated to configure without explicitly setting DISTCHECK_CONFIGURE_FLAGS? erm... isn't --host enabling cross-compiling? And when cross-compiling, make check always fails with some cannot execute binary or so, so distcheck would always fail? Or do I miss something? oki, Steffen
Re: cross-compiling on 64 to 32-bit Linuxlocalhost/
Hi Gregory, On 3/2/2010 4:14 PM, Grégory Pakosz wrote: ./configure --host=i686-pc-linux-gnu \ --prefix=/arch/x86-linux/gnu \ CC=gcc -m32 -march=i586 \ CXX=g++ -m32 -march=i586 \ LDFLAGS=-m32 I'm curious about why setting --host=i686-pc-linux-gnu is not enough to achieve cross compiling and why in that case it's not up to autoconf to add -m32 to CC. You don't need to specify -m32 if you have a tool set prefixed with the cross tag. The reason for using -m32 is because the user wants to use his 64-bit gcc to compile 32-bit code, so he has to tell the compiler to switch to 32-bit mode also. (Incidentally, if you're running on Linux, might also be a good idea to tell the compiler you're running in a 32-bit environment by executing gcc with linux32). Another way to use your 64-bit gcc without special compiler flags is to create scripts, named with the cross prefix, in your bin directory that execute the compiler in 32-bit mode (and perhaps also executed by linux32). Then these tools will be preferred by Autoconf when you use --host=. Regards, John
Re: distcheck and canonical_*
* Steffen Dettmer wrote on Wed, Mar 03, 2010 at 12:21:32AM CET: On Fri, Feb 26, 2010 at 2:55 PM, NightStrike wrote: When doing a make distcheck, why is for instance the --host option not propagated to configure without explicitly setting DISTCHECK_CONFIGURE_FLAGS? erm... isn't --host enabling cross-compiling? And when cross-compiling, make check always fails with some cannot execute binary or so, so distcheck would always fail? NightStrike's package is very specialized: by default it will run on 64-bit Windows only, because it's part of the support package for MinGW64 (or so I assume). So, since the package already requires a cross compilation environment, it might as well also require an emulator to be able to execute tests for a successful distcheck. wine comes to mind for this, together with binfmt-support to automatically execute w32 binaries using wine. Cheers, Ralf
