ether we are cross compiling... no
checking for object suffix... o
checking for executable suffix...
Where did the Cygwin and Mingw checks go?
A quick looksie at the ChangeLog says they were removed
for some reason.
2000-10-12 Akim Demaille <[EMAIL PROTECTED]>
Don't
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
Mo> Whats the deal?
That's the result of our hesitations about this issues, and the fact
that we couldn't even come up with a precise definition of what EXEEXT
and OBJEXT are.
For a start: are they related to host, or to build?
Once things ar
Akim Demaille wrote:
>
> > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> Whats the deal?
>
> That's the result of our hesitations about this issues, and the fact
> that we couldn't even come up with a precise definition of what EXEEXT
> and OBJEXT are.
>
> For a start: are they rel
Akim Demaille wrote:
>
> > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> Whats the deal?
>
> That's the result of our hesitations about this issues, and the fact
> that we couldn't even come up with a precise definition of what EXEEXT
> and OBJEXT are.
>
> For a start: are they rel
Eric Christopher wrote:
>
> Akim Demaille wrote:
> >
> > > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
> >
> > Mo> Whats the deal?
> >
> > That's the result of our hesitations about this issues, and the fact
> > that we couldn't even come up with a precise definition of what EXEEXT
> > and
On 17 Nov 2000, Akim Demaille wrote:
> > "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes:
>
> Mo> Whats the deal?
>
> That's the result of our hesitations about this issues, and the fact
> that we couldn't even come up with a precise definition of what EXEEXT
> and OBJEXT are.
>
> For a start
On Nov 17, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> I always assumed that EXEEXT and OBJEXT were based on the
> host. After all, they should depend on the output of the compiler,
> right?
Agreed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Develope
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 .obj object files
regardless of its hos
On 18 Nov 2000, 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 Cygw
On Sat, Nov 18, 2000 at 05:26:32AM -0800, Mo DeJong wrote:
>On 18 Nov 2000, 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
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
--- 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
> >
>
* 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
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
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
> > >
> >
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
> -Original Message-
> From: Morten Eriksen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 22, 2000 11:38 PM
> To: Paul Berrevoets
> Cc: [EMAIL PROTECTED]
> Subject: Re: Where did the Cygwin and Mingw checks go?
>
>
> Paul Berrevoets <[EMAIL PROTEC
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
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
"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
