Hi Stefan,
Sorry for the huge delay. I waited a while for comments, and then
forgot about this.
* Stefan Seefeld wrote on Sat, Nov 12, 2005 at 04:24:39PM CET:
> Ralf Wildenhues wrote:
> >
> >Not that I know of. You can always define your own macro, for example
> >a fixed version with the same n
Ralf Wildenhues wrote:
Hi Stefan,
* Stefan Seefeld wrote on Fri, Nov 11, 2005 at 06:08:29PM CET:
Ralf Wildenhues wrote:
Does the patch below fix it?
It looks good, though there is at least one more extension: '.inf',
which is generated with optimization. Other files with extensions
'.dbo'
Hi Stefan,
* Stefan Seefeld wrote on Fri, Nov 11, 2005 at 06:08:29PM CET:
> Ralf Wildenhues wrote:
>
> >Does the patch below fix it?
>
> It looks good, though there is at least one more extension: '.inf',
> which is generated with optimization. Other files with extensions
> '.dbo', '.dla', etc.
Ralf Wildenhues wrote:
Does the patch below fix it?
It looks good, though there is at least one more extension: '.inf',
which is generated with optimization. Other files with extensions
'.dbo', '.dla', etc. are created when object files are produces,
but these don't seem to confuse configure.
Hi Stefan,
* Stefan Seefeld wrote on Fri, Nov 11, 2005 at 03:31:18PM CET:
> I'm using autoconf with a greenhills cross-compiler.
> It compiles source code into .ppc executables, but
> generates auxiliary files with other extensions on-the-fly
> (.map, for example).
Does the patch below fix it?
>
I'm using autoconf with a greenhills cross-compiler.
It compiles source code into .ppc executables, but
generates auxiliary files with other extensions on-the-fly
(.map, for example).
Unfortunately, the way autoconf detects a compiler's
default executable extension is by making some guesses,
and
Is there anything like a guide to how EXEEXT should be incorporated into a
build system?
I'm currenty able to build RSYNC on OS/2 using the standard autoconf,
configure, make process, but need so manual intervention to convert the
final binary file into a .EXE. I think I could get the
hing is that it appears that autoconf has indeed
changed the no-exeext value, so config.caches can no longer be shared
between configure scripts built using autoconf 2.13 and those built
with autoconf 2.50. I suppose autoconf should have renamed the cache
variable when its contents changed.
Anyway, th
2000-01-19 Lars J. Aas <[EMAIL PROTECTED]>
* aclang.m4 (_AC_COMPILER_EXEEXT_*): export ac_cv_exeext
+
Please, don't do that.
OK with me, and in the cvs commit queue.
I suggested this one before, but there was never any comments, so
here's a more "official" submittal... I know it's kind of "the wrong
fix", but a right fix won't help with the latest released libtool,
and a new libtool release can be some time off...
2000-01-19 Lars J. Aas <[EMAIL PROTECTED]>
s <[EMAIL PROTECTED]>
* aclang.m4 (_AC_COMPILER_EXEEXT_DEFAULT,_AC_COMPILER_EXEEXT_O):
Export ac_cv_exeext to environment to override incorrect exeext
test in ltconfig from libtool-1.3.5.
Index: aclang.m4
===
RCS file:
I thought I had sent this before, but I'm not sure I did... Sorry if
it's a duplicate.
On Dec 15, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> +if ls a.* >/dev/null 2>&1; then
> + rm -rf conftestdir
> + mkdir conftestdir
> + mv a.* conftestdir
> +fi
[snip]
> +if test -d conftestdir; then
> -Original Message-
> From: Akim Demaille [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 3:49 PM
> To: Bernard Dautrevaux
> Cc: Alexandre Oliva; Mo DeJong; [EMAIL PROTECTED]; APatche
> Subject: Re: EXEEXT: `cc -o' (Was: AC_CYGWIN etc.)
>
>
>
| > +AS_IFELSE([AC_TRY_EVAL(ac_link)],
| > + [for ac_file in `ls a.exe conftest.exe a.*
| > conftest.* 2>/dev/null`; do
|
| Here one may also check for plain "conftest"; this saves the second link :-)
|
| for ac_file in `ls a.exe conftest.exe conftest a.* conftest.* 2>/dev/null`;
| do
> -Original Message-
> From: Akim Demaille [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 3:06 PM
> To: Bernard Dautrevaux
> Cc: Alexandre Oliva; Mo DeJong; [EMAIL PROTECTED]; APatche
> Subject: Re: EXEEXT: `cc -o' (Was: AC_CYGWIN etc.)
>
>
*.d | *.pdb ) ;;
-*) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`
+*) ac_cv_exeext=`expr "$ac_file" : '[^.]*\(\..*\)'`
break;;
esac
done],
[AC_MSG_ERROR([cannot compute EXEEXT: cannot compile and link])])
-rm -f conftest$
| Looks fine but what about compilers, I know a few of them, that generates
| and executable named after the first source or object file listed if no '-o'
| option is given; for example:
| $(CC) xxx.c yyy.o
| will generate xxx, or maybe xxx.exe if the host request it.
No kidding!?!? I'l
> -Original Message-
> From: Akim Demaille [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 15, 2000 10:42 AM
> To: Alexandre Oliva
> Cc: Mo DeJong; [EMAIL PROTECTED]; APatche
> Subject: EXEEXT: `cc -o' (Was: AC_CYGWIN etc.)
>
>
>
> Here is my pro
+ 2>/dev/null`; do
case $ac_file in
*.$ac_ext | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb ) ;;
*) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`
@@ -675,7 +705,24 @@
esac
done],
[AC_MSG_ERROR([cannot compute EXEEXT: cann
xeext not ac_cv_exeext
+ac_exeext_save=$ac_exeext
+ac_exeext=$ac_cv_exeext
+_AC_LINK_IFELSE([],
[# If both `conftest.exe' and `conftest' are `present' (well, observable)
# catch `conftest.exe'. For instance with Cygwin, `ls conftest' will
# work properly (i.e., refer
`ls conftest$ac_cv_exeext conftest.exe conftest conftest.* \
+ 2>/dev/null`; do
case $ac_file in
*.$ac_ext | *.o | *.obj | *.xcoff | *.tds | *.d | *.pdb ) ;;
*) ac_cv_exeext=`expr "$ac_file" : 'conftest\(.*\)'`
@@ -675,7 +701,24 @@
esa
22 matches
Mail list logo
