mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] mingw-w64 and mingw-cross-env


From: LM
Subject: Re: [Mingw-cross-env-list] mingw-w64 and mingw-cross-env
Date: Wed, 21 Mar 2012 08:42:48 -0400

On Tue, Mar 20, 2012 at 4:24 PM, Volker Grabsch <address@hidden> wrote:
> Those target names are indeed meant to be used as ./configure
> arguments, not just for the file structure.
>
> You are absolutely right that we should make a real
> test run to check that the new target names won't
> cause any issues.
>
> I didn't ever see a build script  which checks for the
> VENDOR part of the target. However, some helper scripts
> like config.guess might have trouble with "mingw" instead
> of "mingw32", or with the pseudo vendor string
> (static/dynamic). Also, what's with Qt/QMake and with
> CMake? We should really check that.

Probably not the same thing, but I've changed the MSYSTEM variable
used with msys from mingw32 to watcom (as recommended by the mingw
project) when I was building some applications using owcc and msys and
had issues with configure scripts not knowing what platform to build
for.  The change affects the uname command which is sometimes used to
autogenerate part of the triplet.  Was concerned, if the configure
script runs across a system it doesn't recognize, it may just give up.
 I've had to go in and add something for the watcom compiler to the
list of targets before.  I would definitely recommend testing a change
to the build name out with different configure scripts.  I've only
seen issues on some.  I haven't noticed any issues with the vendor
either.   I have noticed occasionally when I supply too much
information to the configure command line it won't run.  Sometimes
it's better to let it autoguess.

Was thinking, one could use *-*-mingw32 for mingw.org (32 bit) and
*-*-mingw64 for mingw-w64.sourceforge.net (64 bit).  However, a quick
search yields some interesting information on naming conventions:
http://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3013292
http://www.cygwin.com/ml/binutils/2007-01/msg00078.html
http://comments.gmane.org/gmane.comp.compilers.clang.devel/6171
Sounds like there are other people having similar problems with naming
conventions.  I personally like being able to get some indication of
the compiler in the os part.  I've seen it done with djgpp which
usually uses *-*-msdosdjgpp.  However, this appears to be more of an
exception rather than a rule.  Then again, if we were going strictly
by operating system (as mentioned
http://airs.com/ian/configure/configure_4.html ), shouldn't it be
*-*-win32 which I've also seen commonly used, not *-*-mingw32 which a
lot of configure scripts currently use?  Most Linux systems can
probably safely assume if it's linux-gnu, you're using a gnu compiler.
 However, for Windows, that's not true.  There's mingw (mingw.org),
mingw32 and mingw64, openwatcom, visual c++, etc.  Also, llvm is
becoming more popular (especially on Mac and BSD systems).  It would
be nice to have some indication of compiler because at least for C++
libraries, they're usually compiler specific.

I don't know about getting the qtmake/cmake to someone's platform and
configured appropriately, but presumably the project isn't concerned
with getting autoconfigure and make to everyone's platform either.
Since the configure and make commands are in each program's .mk file,
one can just replace with relevant cmake or qtmake commands for the
applications/libraries expecting one to use them instead.  I've hit
issues on the Windows side when trying to build qt libraries on
Windows.  The qt site supplies its own patched version of mingw and
it's not the latest version either.  I'm guessing patches will be
needed to make certain qt based libraries/apps build properly with a
cross-compiler.  Would be nice to eventually get webkit or v8 building
by script though.  With cmake, most of the time I haven't had issues
with it on various platforms, but I used it with msys on Windows
recently when I was attempting to build a program that used it and all
the default paths set up by cmake were looking for libraries in the
wrong locations.  Don't recall ever having to specifically pass the
triplet information to cmake or qtmake when I used them in the past.
However, I really haven't worked with them that often.

Will be very interested to see how the triplet naming conventions work
out for mingw-cross-env.

Sincerely,
Laura



reply via email to

[Prev in Thread] Current Thread [Next in Thread]