Alexandre Oliva wrote:
>
> On Nov 17, 2000, Eric Christopher <[EMAIL PROTECTED]> wrote:
>
> > So a solaris cross cygwin compiler would define EXEEXT to be .exe,
> > however, OBJEXT would be .o because it was compiled on a solaris
> > box.
>
> I suppose a compiler that targets Cygwin will create
On Nov 20, 2000, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
>> I suppose a compiler that targets Cygwin will create .obj object files
>> regardless of its host platform.
> Hmm, I don't think so.
I stand corrected. Anyone can tell I keep off MS-Windows as much as
possible :-)
--
Alexandre Oliv
On Mon, Nov 20, 2000 at 02:51:47AM -0200, Alexandre Oliva wrote:
>On Nov 20, 2000, Ralf Corsepius <[EMAIL PROTECTED]> wrote:
>>> I suppose a compiler that targets Cygwin will create .obj object files
>>> regardless of its host platform.
>
>> Hmm, I don't think so.
>
>I stand corrected. Anyone can
Hi,
I'm working on a project with a pretty large (and increasing)
number of configure parameters, so I look for ways to store sets
of parameters externally, such that they be used much like config.cache,
if desired. Since all possible arguments could be known from the macros
used in configure.in,
> I'm working on a project with a pretty large (and increasing)
> number of configure parameters, so I look for ways to store sets
> of parameters externally, such that they be used much like config.cache,
> if desired. Since all possible arguments could be known from the macros
> used in config
Even after setting /cygdrive to binary mode, the problem with
fopen(file, "w") persists (since I had fixed my own autoconf
repository to use "wb" I didn't notice it until I tried to configure
glib which has it's own set of macros like that.
I suspect that it is related to the fact that I'm using
--- Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> No, it depends in what your compiler outputs.
>
> % cat tmp.c
> int i;
>
> % i386-mingw32msvc-gcc -c tmp.c
>
> % ls tmp.*
> tmp.c tmp.o
>
> % ./i586-cygwin32-gcc -c tmp.c
>
> % ls tmp.*
> tmp.c tmp.o
>
> You would only get a .obj file if you
On Mon, 20 Nov 2000, Earnie Boyd wrote:
> --- Mo DeJong <[EMAIL PROTECTED]> wrote:
> >
> > No, it depends in what your compiler outputs.
> >
> > % cat tmp.c
> > int i;
> >
> > % i386-mingw32msvc-gcc -c tmp.c
> >
> > % ls tmp.*
> > tmp.c tmp.o
> >
> > % ./i586-cygwin32-gcc -c tmp.c
> >
>
When the w32 free Borland C++ command line compiler links a program
(conftest.exe), it also produces a file named `conftest.tds' in
addition to `conftest.obj'. In AC_OBJEXT, conftest.* is globbed to
`... conftest.obj conftest.tds', and the for loop ends up deciding
that $ac_objext should be `tds'
I've searched Google and the mailing list for help on this to no avail.
Perhaps someone can help me. (I'm using Autoconf 2.13 with Cygwin.)
How can I add a define to a Makefile such as this:
... -DCONFIG_DIR=$(sysconfdir)
The thing I thought would work in configure.in:
AC_DEFINE(CONFIG_DIR, "$
On Tue, Nov 21, 2000 at 05:23:08PM -0500, Town, Brad wrote:
> I've searched Google and the mailing list for help on this to no avail.
> Perhaps someone can help me. (I'm using Autoconf 2.13 with Cygwin.)
>
> How can I add a define to a Makefile such as this:
>
> ... -DCONFIG_DIR=$(sysconfdir)
>
* Mo DeJong
> I was under the impression that autoconf would just try to compile
> conftest.c and then find the obj extension by looking for files
> named conftest.*, filtering out conftest.c and then using whatever
> was left (either conftest.o or conftest.obj). That might have
> changed, but it
--- Mo DeJong <[EMAIL PROTECTED]> wrote:
>
> Why would this depend on uname? I was under the impression that
> autoconf would just try to compile conftest.c and then find
> the obj extension by looking for files named conftest.*,
> filtering out conftest.c and then using whatever was left
> (eith
Hi,
given this configure.in (a useless case, but it'll serve as an
example):
== [snip]
AC_INIT(configure.in)
AC_CONFIG_HEADER(config.h)
if false; then
AC_PATH_XTRA
else
AC_PATH_XTRA
fi
AC_OUTPUT
== [snip]
..the r
On Wed, 22 Nov 2000, Earnie Boyd wrote:
> --- Mo DeJong <[EMAIL PROTECTED]> wrote:
> >
> > Why would this depend on uname? I was under the impression that
> > autoconf would just try to compile conftest.c and then find
> > the obj extension by looking for files named conftest.*,
> > filtering ou
Akim Demaille <[EMAIL PROTECTED]> writes:
> Could you try to see what happened? Rerun the corresponding debug.sh,
> and run `../autoupdate -A .. - with `77'.
$ ./debug-111.sh
==
./debug-111.sh: Testing autoupdate
==
/tmp/joda/aut
--- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> Even after setting /cygdrive to binary mode, the problem with
> fopen(file, "w") persists (since I had fixed my own autoconf
> repository to use "wb" I didn't notice it until I tried to configure
> glib which has it's own set of macros like that.
>
>
On Wed, Nov 22, 2000 at 11:13:15AM -0800, Earnie Boyd wrote:
: Oh, I get it,
: it's cl that's creating the program that outputs the lines that contains the
: \r\n. This means that your "wb" would cause the cl created program to output
: only \n line endings and would be read appropriately with Cy
Mo DeJong wrote:
> On Mon, 20 Nov 2000, Earnie Boyd wrote:
>
> > --- Mo DeJong <[EMAIL PROTECTED]> wrote:
> > >
> > > No, it depends in what your compiler outputs.
> > >
> > > % cat tmp.c
> > > int i;
> > >
> > > % i386-mingw32msvc-gcc -c tmp.c
> > >
> > > % ls tmp.*
> > > tmp.c tmp.o
> > >
> >
On Wed, Nov 22, 2000 at 03:50:58PM -0500, Paul Berrevoets wrote:
: This is ok for AC_OBJEXT, but for AC_EXEEXT please take into consideration that on
: UWIN (which uses a cc wrapper for MSVC), the compiler also generates a .pdb file,
: which if you don't filter it out along with .obj, would be use
But you and I were both talking about files that get generated at link time. AC_OBJEXT
does not link, and therefore should be no problem. The problem lies in AC_EXEEXT. Your
technique needs to be modified somewhat because you are not using file globbing for
'conftest.o' and 'conftest.obj'. How abo
--- "Lars J. Aas" <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 22, 2000 at 11:13:15AM -0800, Earnie Boyd wrote:
> : Oh, I get it,
> : it's cl that's creating the program that outputs the lines that contains
> the
> : \r\n. This means that your "wb" would cause the cl created program to
> output
> : o
On Wed, Nov 22, 2000 at 04:45:40PM -0500, Paul Berrevoets wrote:
: But you and I were both talking about files that get generated at link time.
:AC_OBJEXT
: does not link, and therefore should be no problem.
Yes, ideally. However, the Borland C++ compiler wrapper we're using doesn't
detect that
Paul Berrevoets <[EMAIL PROTECTED]> writes:
> [...] for AC_EXEEXT please take into consideration that on UWIN
> (which uses a cc wrapper for MSVC), the compiler also generates a
> .pdb file, which if you don't filter it out along with .obj, would
> be used as the extension for executables.
I've
"Lars J. Aas" wrote:
> : Your technique needs to be modified somewhat because you are not using file
> : globbing for 'conftest.o' and 'conftest.obj'.
>
> That is because I tested for the existence of the file in the loop.
Clearly ... my bad :-(
--
Paul
25 matches
Mail list logo
