Re: [PATCH] Add tests about support of wildcards in EXTRA_DIST
At Saturday 20 February 2010, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * tests/extra10.test: New test, check basic support of wildcards in EXTRA_DIST. * tests/extra11.test: New test, check more complex usage of wildcards in EXTRA_DIST. * tests/extra11.test: New test, check usage of wildcards in EXTRA_DIST when $builddir != $srcdir. D'oh! I managed to mess up the ChangeLog entry: this should be `extra12.test', not `extra11.test'. I'm really sorry about this stupid mistake. The attached patch should fix it in the ChangeLog file (unfortunately, the git log contains the same error, but it can't be fixed without editing the git repository, which IIRC is a big no-no for published repos). Again, my apologies for the mistake, Stefano From 298876462fbfec7e8d6dfea035da3c10071a927c Mon Sep 17 00:00:00 2001 From: Stefano Lattarini stefano.lattar...@gmail.com Date: Wed, 3 Mar 2010 15:06:51 +0100 Subject: [PATCH] Fix stupid mistake in ChangeLog * ChangeLog (2010-02-20 ... Add tests about support of wildcards in EXTRA_DIST): Correctly cite test script `extra12.test' rather than citing two times test script `extra11.test'. --- ChangeLog |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5fbc889..a0b620b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -35,7 +35,7 @@ in EXTRA_DIST. * tests/extra11.test: New test, check more complex usage of wildcards in EXTRA_DIST. - * tests/extra11.test: New test, check usage of wildcards in + * tests/extra12.test: New test, check usage of wildcards in EXTRA_DIST when $builddir != $srcdir. * tests/Makefile.am (TESTS): Updated accordingly. Necessity of these new tests suggested by Braden McDaniel -- 1.6.5
Re: [PATCH] Add tests about support of wildcards in EXTRA_DIST
Hi Stefano, * Stefano Lattarini wrote on Wed, Mar 03, 2010 at 03:12:35PM CET: * tests/extra10.test: New test, check basic support of wildcards in EXTRA_DIST. * tests/extra11.test: New test, check more complex usage of wildcards in EXTRA_DIST. * tests/extra11.test: New test, check usage of wildcards in EXTRA_DIST when $builddir != $srcdir. D'oh! I managed to mess up the ChangeLog entry: this should be `extra12.test', not `extra11.test'. Thanks, and don't worry. Cheers, Ralf
Re: cross-compiling on 64 to 32-bit Linuxlocalhost/
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=. Thanks for your answer John, In fact I believed autoconf could have done all the job for me: that is invoking 64bit gcc with -m32 after having detected there is no i686-pc-linux-gnu compiler available :) But maybe it's rare to be in this situation? I'm building a closed source shared library that only depends on libc which is why I don't really need a chroot environment. For now, to ease my coworkers life, I came up with a shell script that does a little analysis before invoking configure: based on uname and gcc --print-multi-lib, it creates several build directories like build/linux/i386 and/or build/linux/x86_64 and invokes configure from there with proper CC overrides. Regards, Gregory
Automake and AR
Automake somehow defines AR to 'ar'. I'm not sure where this comes from, but I do know that it's definitely not $host-ar, as I would expect. Is this an automake bug, or user error?
Re: Public header files
Jef Driesen jefdrie...@hotmail.com writes: 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. long long has been standard for 11 years now. It is irritating that some vendors have apparently not updated their C compilers in that long. -- Ben Pfaff http://benpfaff.org
Re: Public header files
Hi Jef, On 3/3/2010 11:53 AM, Ben Pfaff wrote: Jef Driesenjefdrie...@hotmail.com writes: 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. long long has been standard for 11 years now. It is irritating that some vendors have apparently not updated their C compilers in that long. While I agree that standards should be followed, I find this one distasteful. I mean, long long? Is that supposed to be someone's idea of a scalable solution? What happens when we have 128-bit systems? Dare I venture: long long long? And please don't say we'll never have 128-bit systems. We've been down that road before; we know where it leads. Personally, I like the idea of using int64_t and uint64_t. The exact same standard already defines such types for the more commonly used sizes, and it is scalable. John
AM_PROG_AS
Using AM_PROG_AS seems to set AS to 'as' instead of $host-as. Is this another case of user error, or is this an automake bug?
Re: Public header files
Sorry - I addressed this note to Jef. It should have gone to Ben. My apologies. On 3/3/2010 12:16 PM, John Calcote wrote: Hi Jef, On 3/3/2010 11:53 AM, Ben Pfaff wrote: Jef Driesenjefdrie...@hotmail.com writes: 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. long long has been standard for 11 years now. It is irritating that some vendors have apparently not updated their C compilers in that long. While I agree that standards should be followed, I find this one distasteful. I mean, long long? Is that supposed to be someone's idea of a scalable solution? What happens when we have 128-bit systems? Dare I venture: long long long? And please don't say we'll never have 128-bit systems. We've been down that road before; we know where it leads. Personally, I like the idea of using int64_t and uint64_t. The exact same standard already defines such types for the more commonly used sizes, and it is scalable. John
Re: unconditional version of EXTRA_DIST
Hello Andreas, * Andreas Jellinghaus wrote on Wed, Mar 03, 2010 at 02:11:52PM CET: I'm told EXTRA_DIST files are optional - automake will include them if they exist, but also go on, if those files do not exist. No, that is not true. Just try EXTRA_DIST = does-not-exist and 'make dist' will fail. dist_DATA or something like that? dist_DATA is distributed but also 'make install' will put it in $(datadir). Cheers, Ralf
Re: distcheck and canonical_*
On Wed, Mar 3, 2010 at 1:03 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * 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. Correct. And 64-bit Wine actually works pretty well.
Re: Automake and AR
* NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET: Automake somehow defines AR to 'ar'. I'm not sure where this comes from, but I do know that it's definitely not $host-ar, as I would expect. Is this an automake bug, or user error? Looks like an automake bug to me. Just putting AC_CHECK_TOOL([AR], [ar], [false]) somewhere in configure.ac should serve as a workaround though. Thanks for the report, will fix, Ralf
Re: Public header files
John Calcote john.calc...@gmail.com writes: While I agree that standards should be followed, I find this one distasteful. I mean, long long? Is that supposed to be someone's idea of a scalable solution? What happens when we have 128-bit systems? Dare I venture: long long long? And please don't say we'll never have 128-bit systems. We've been down that road before; we know where it leads. Usually by the time one gets to the point of standardizing something, it's both too late to fix the aesthetics and aesthetics are the least of anyone's concerns. A lot of things that make it into standards are widespread existing practice before then, and it's too much work to change them. I suspect this is part of why, as you point out, the standard also introduces intsize_t at the same time, but long long is more widely supported, probably because it's older than the standard. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: Automake and AR
On Wed, Mar 3, 2010 at 2:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET: Automake somehow defines AR to 'ar'. I'm not sure where this comes from, but I do know that it's definitely not $host-ar, as I would expect. Is this an automake bug, or user error? Looks like an automake bug to me. Just putting AC_CHECK_TOOL([AR], [ar], [false]) somewhere in configure.ac should serve as a workaround though. Thanks for the report, will fix, Ralf Thanks! I am also noting that in this and previous emails, you are recommending false as the third argument. In the manual, there are numerous locations that serve as examples that imply a colon is the proper choice (and thusly it is what I have used). Which is better?
Re: Public header files
On 3/3/2010 12:53 PM, Russ Allbery wrote: John Calcotejohn.calc...@gmail.com writes: While I agree that standards should be followed, I find this one distasteful. I mean, long long? Is that supposed to be someone's idea of a scalable solution? What happens when we have 128-bit systems? Dare I venture: long long long? And please don't say we'll never have 128-bit systems. We've been down that road before; we know where it leads. Usually by the time one gets to the point of standardizing something, it's both too late to fix the aesthetics and aesthetics are the least of anyone's concerns. A lot of things that make it into standards are widespread existing practice before then, and it's too much work to change them. I suspect this is part of why, as you point out, the standard also introduces intsize_t at the same time, but long long is more widely supported, probably because it's older than the standard. Of course you're right Russ. John
Re: AM_PROG_AS
* NightStrike wrote on Wed, Mar 03, 2010 at 08:18:14PM CET: Using AM_PROG_AS seems to set AS to 'as' instead of $host-as. Is this another case of user error, or is this an automake bug? AM_PROG_AS does not set AS. This macro is 10 lines long, you could easily have verified that by looking at it. Cheers, Ralf
Re: Automake and AR
* NightStrike wrote on Wed, Mar 03, 2010 at 09:05:25PM CET: On Wed, Mar 3, 2010 at 2:51 PM, Ralf Wildenhues wrote: AC_CHECK_TOOL([AR], [ar], [false]) I am also noting that in this and previous emails, you are recommending false as the third argument. In the manual, there are numerous locations that serve as examples that imply a colon is the proper choice (and thusly it is what I have used). Which is better? Well, for tools like ranlib which is optional and unneeded on many systems it is desirable that the build succeeds without it. If configure doesn't detect ar, you have a problem if you need it, and if you happen to additionally link against your in-tree static library using -L. -lfoo rather than recommended libfoo.a, then a missing ar might now even turn in a bad build, linking against a wrong installed libfoo. This thing is an option precisely because there is no one answer that is always correct. Cheers, Ralf
Re: unconditional version of EXTRA_DIST
* Andreas Jellinghaus wrote on Wed, Mar 03, 2010 at 10:29:50PM CET: Am Mittwoch 03 März 2010 20:32:53 schrieb Ralf Wildenhues: * Andreas Jellinghaus wrote on Wed, Mar 03, 2010 at 02:11:52PM CET: I'm told EXTRA_DIST files are optional - automake will include them if they exist, but also go on, if those files do not exist. No, that is not true. Just try EXTRA_DIST = does-not-exist and 'make dist' will fail. ah. ok, so back to the drawing board for my plan with optional documentation (see the thread a week ago or so). You can use either of - wildcards, EXTRA_DIST = pattern* - automake conditionals, if COND EXTRA_DIST += files... endif - or plain old configure substitutions for variable content in EXTRA_DIST. EXTRA_DIST = file @list_of_files@ $(more_files) Cheers, Ralf
Re: Multiplatform autotools; all OK on Linux, warning on Windows
Hello Joost, * Joost Kraaijeveld wrote on Tue, Mar 02, 2010 at 05:22:07PM CET: 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 The libtool list would have been even better. 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. [...] checked: /home/jkr/src/mingw-cross-env-2.10/usr/lib/gcc/i686-pc-mingw32/4.4.0/../../../../i686-pc-mingw32/lib//libpthread.a Are these warning something I should/can fix? What is it they are trying to tell me? If they are fixable, how? Which libtool version do you use? Is that libpthread.a a static or an import library? There have been some fixes to deplib detection in Libtool recently, not sure whether that can have an impact for you. But anyway the above is only a warning. Cheers, Ralf
