Making ORBit work with MS VS compilers

[Markus Duft]

Tor Lillqvist <> wrote:
>> Then you really should consider trying parity. Although we're on
>>  Interix, there should be no reason to not operate on Cygwin as build
>>  environment.
>
> Maybe with parity it's different but at least when building stuff on
> Windows using the "normal" autofoo and libtool mechanism, I definitely
> recommend staying away from Cygwin and using MSYS instead.

Hm. I haven't tried MSYS, and for sure, parity would understand only
windows style paths there (since there is no MSYS build of parity yet,
which would understand the unix style paths there). This support is
built-in right now for cygwin and interix only.

OTOH unsetting CPATH and such things should keep parity from getting the
wrong headers, it knows about it's own (microsoft's) include
directories, and adds them by itself.

>
> As Cygwin comes with "normal" headers for the libraries it includes in
> /usr/include, and libraries in /usr/lib, with Cygwin there is always
> the risk of confusing Cygwin headers with the headers of depencencies
> you really want to use, and the risk of confusing Cygwin libraries
> with the libraries you really want. At least, that is my experience
> from back when I built the GTK+ stack for Windows on Cygwin, using its
> gcc with the -mno-cygwin switch.
>
> No such risk with MSYS. Even if MSYS technically is a fork of Cygwin,
> MSYS is "just" the runtime where tools like sh, awk, sed and perl run,
> not a development target by itself. Also, the main MSYS feature, i.e.
> the automatic mangling of command-line file name parameters and
> PATH-like environment variables fron Unix form to Windows form is
> quite useful. Cygwin does not do this automatically, you might have to
> insert cygpath calls here and there.

So then it wouldn't matter if parity understood only windows paths (i.e.
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....))? Cool :)

Cheers, Markus

>
> With extreme care it is possible to use Cygwin, sure. For instance the
> way to build Mono on Windows with gcc is to use run the build on
> Cygwin and use gcc -mno-cygwin. But I bet they have had to be quite
> careful when constructing their Makefiles.
>
> --tml

_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

>  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:\stuff\subdir\where)

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@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Markus Duft]

Tor Lillqvist <> wrote:

>>  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:\stuff\subdir\where)
>
> 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.

I see... So parity would get to see only windows paths? That would be ok
then. _Maybe_ things work out ot the box :) If not i'll be happy to look
into it, but i need a MSYS environment first... Arg... :)

Cheers, Markus

>
> --tml

_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Marcelo Vanzin]

Hi,

Just to let you guys know that I have files 4 bugs and attached patches:

524061   ORBit2   UNCO   enh   Patch: fix orbit2 so it compiles with MSVC
524058 ORBit2 UNCO enh Patch: fix idl-compiler so it compiles with MSVC
524056 ORBit2 UNCO enh Patch: fix linc2 so it compiles with MSVC
522697 libIDL UNCO enh Patch: make libIDL work with Microsoft's compilers

Note that this does not yet change the code generated by orbit-idl-2,
nor it generates a working ORBit2 dll. That will require some extra
work and a larger patch, but now at least things compile with VC. :-)

--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Michael Haubenwallner]

On Sun, 2008-03-23 at 18:43 -0700, Marcelo Vanzin wrote:

> Hi,
>
> Just to let you guys know that I have files 4 bugs and attached patches:
>
> 524061   ORBit2   UNCO   enh   Patch: fix orbit2 so it compiles with MSVC
> 524058 ORBit2 UNCO enh Patch: fix idl-compiler so it compiles with MSVC
> 524056 ORBit2 UNCO enh Patch: fix linc2 so it compiles with MSVC
> 522697 libIDL UNCO enh Patch: make libIDL work with Microsoft's compilers
>
> Note that this does not yet change the code generated by orbit-idl-2,
> nor it generates a working ORBit2 dll. That will require some extra
> work and a larger patch, but now at least things compile with VC. :-)
>

Attached is our patch for ORBit2-2.14.2, which also fixes the idl
compiler to create code that can be built into a Windows dll.

But there are two issues with this patch (because we do not need it as
real Interix binary):
1) The build environment is assumed to be Interix - there's nothing done
for Cygwin or MSYS.
2) Even if the target is Interix itself (not native Windows using
parity), it eventually assumes that it is built using parity.

HTH,

/haubi/


_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Marcelo Vanzin]

Hi Michael,

On Wed, Mar 26, 2008 at 8:52 AM, Michael Haubenwallner
<michael.haubenwallner@...> wrote:
>  Attached is our patch for ORBit2-2.14.2, which also fixes the idl
>  compiler to create code that can be built into a Windows dll.

Thanks for posting this! I took a quick look and your approach looks
very similar to the code I wrote a couple of weeks ago (not the
patches I posted to bugzilla). Which makes me think that the issues
Tor was worried about might not be issues with newer MS compilers. :-)

--
Marcelo Vanzin
mmvgroups@...
"Life's too short to drink cheap beer."
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

>  Which makes me think that the issues
>  Tor was worried about might not be issues with newer MS compilers. :-)

That would be very good news indeed. I really need to find time to
refresh my memory of the technical details, and find simple test
programs that exhibit the problem and require using the
--enable-runtime-pseudo-reloc switch in the GNU linker.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Tor Lillqvist]

> Attached is our patch for ORBit2-2.14.2, which also fixes the idl
> compiler to create code that can be built into a Windows dll.

Sorry for taking so long to get back to this issue... I haven't really
done anything about this in the meantime. I had a look at this patch
now.

The patch changes this in Makefile.shared:

- $(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<
+ if test `uname` = "Interix" ; then \
+ $(IDL_COMPILER) $(IDL_FLAGS_W32) --deps $(*D)/.deps/$(*F).idl.P
`unixpath2win $<`; \
+ else \
+ $(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<; \
+ fi

Surely this approach can't be feasible in the long run? If the
eventual goal is for instance to make those modules in the GNOME stack
that currently can be built for Win32 with mingw on msys also
buildable with parity on Interix, aren't there hundreds of Makefiles
and other places where similar stuff would need to be changed then?
Ditto for the other parts in the diff where unixpath2win is involved.

Is it possible to use "mounts" like MSYS in Interix? I.e., is it
possible to make an Interix "Unix" path like /foo/bar refer to the
same actual location as the Win32 path X:\foo\bar? (Where X: is the
drive you are doing the work on, hopefully you don't have to use
several drive letters) Then one could simply require that such mounts
are used and no unixpath2win invocations would be needed to be added
all over the place.

I think at least currently Interix is not really that popular among
people porting software from Unix to Windows. I don't feel it would be
worth it at this point at least to apply your patch to the sources,
sorry.

--tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list

[Markus Duft]

>
> > Attached is our patch for ORBit2-2.14.2, which also fixes the idl
> > compiler to create code that can be built into a Windows dll.
>
> Sorry for taking so long to get back to this issue... I haven't really
> done anything about this in the meantime. I had a look at this patch
> now.
>
> The patch changes this in Makefile.shared:
>
> - $(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<
> + if test `uname` = "Interix" ; then \
> + $(IDL_COMPILER) $(IDL_FLAGS_W32) --deps

$(*D)/.deps/$(*F).idl.P
> `unixpath2win $<`; \
> + else \
> + $(IDL_COMPILER) $(IDL_FLAGS) --deps
$(*D)/.deps/$(*F).idl.P $<; \
> + fi
>
> Surely this approach can't be feasible in the long run? If the
> eventual goal is for instance to make those modules in the GNOME stack
> that currently can be built for Win32 with mingw on msys also
> buildable with parity on Interix, aren't there hundreds of Makefiles
> and other places where similar stuff would need to be changed then?
> Ditto for the other parts in the diff where unixpath2win is involved.

First of all Hi :)

Parity got better in the meantime, and any binary that is built with
parity understands all kinds of paths, also interix ones. So the
unixpath2win can be omitted if $IDL_COMPILER points to a binary that was
built with parity (which should be the case anyway)

>
> Is it possible to use "mounts" like MSYS in Interix? I.e., is it
> possible to make an Interix "Unix" path like /foo/bar refer to the
> same actual location as the Win32 path X:\foo\bar? (Where X: is the
> drive you are doing the work on, hopefully you don't have to use
> several drive letters) Then one could simply require that such mounts
> are used and no unixpath2win invocations would be needed to be added
> all over the place.

On interix /dev/fs/C maps to C:. there is no other means of mounting
anything.... but the whole last paragraph is obsolete because as I said
already, parity built binaries can handle both styles of paths, even if
you mix them (only exception: in a path list (separated by : on interix,
and ; on windows) all paths must be the same style (either windows or
unix) or otherwise the path conversion routines will get confused...)

>
> I think at least currently Interix is not really that popular among
> people porting software from Unix to Windows. I don't feel it would be
> worth it at this point at least to apply your patch to the sources,
> sorry.

Hmm... yeah, but interix _will_ get popular I think/hope/believe, since
I made a port of Gentoo Prefix to interix, which enables even the use of
gnome-terminal. From there onwards I'm just working on being able to
build native windows binaries too, which would make things really cool
:)

Cheers, Markus

>
> --tml
_______________________________________________
orbit-list mailing list
orbit-list@...
http://mail.gnome.org/mailman/listinfo/orbit-list