> it was built with cl.exe as native win32 executable,
and not with mingw
> gcc (which i think would result in a mess, since the
compiler couldn't
> convert the mingw unix style paths to something that
cl.exe
> understands....))?
You misunderstand. MinGW produces native Win32 executables,
exactly
like cl does. That's the point of it, to be a more or less
direct
functional equivalent of cl.exe, link.exe et al.
The MinGW programs (gcc, ld, nm etc) are also native Win32
exectuables
themselves. They don't understand Unix style paths.
"mingw unix style
paths" don't exist.
But when used from a MSYS shell or make, that doesn't
matter, as MSYS
takes care of converting for instance command-line
parameters like
-I /where/ever/include
that uses a MSYS Unix style path into
-I x:/stuff/subdir/where/ever/include
when running gcc. (If /where is "mounted" in the
MSYS sense on
x:stuffsubdirwhere)
Now, MinGW is *usually* used from a MSYS shell or make, so
it is
perhaps easy to con-fuse them. But they are separate
things.
--tml
_______________________________________________
orbit-list mailing list
orbit-list gnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list
|