RE: Making ORBit work with MS VS compilers

Tor Lillqvist <> wrote:
>> You might want to have a look at parity[1]
(formerly called wgcc[2])
>>  to build native Windows binaries using
VisualStudio compilers.
> 

First of all, Hi 

I'm the author of parity.

> Is there any webpage give a higher-level technical
description of what
> parity is? Apparently it is (yet another) wrapper for
the Microsoft
> toolchain to make their command-line interface be more
like that of

There is no webpage (yet), and yes, it's a wrapper around
Microsoft's
tools, to make it look (and as far as possible also behave)
like gcc.

> gcc? Briefly looking in the sources, it apparently also
then
> additionally supports some of the Linux run-time linker
features, like
> LD_PRELOAD? (But the usefulness of that when still
using PE format
> executables (.exe and .dll) is somewhat limited, isn't
it?)

Yes it adds support for LD_PRELOAD and such things, but that
doesn't
influence compat to all other windows libraries. Everything
built with
parity can be linked with any other native thing (the only
thing is,
that the naming of the files is different. The .so files are
the import
libs to link to (normally .lib). This was done this way to
make things a
lot easier while porting...)

This means you can just add such a parity-built .so file to
the linker
command line in visual studio and it will work. All the
things that
parity adds are really private for each binary that is
linked.

> 
> Hmm, the ReleaseNotes.txt says "It relies on the
presence of a UNIX
> Layer for Windows such as Interix, Cygwin or
MinGW" which doesn't make
> sense, as MinGW is not a UNIX Layer in the same sense
as Interix or
> Cygwin at all. On the other hand right after is says
"This results in

Oops, should be MSYS instead of MinGW, although i didn't try
it there.
Interix is the best tested one, there i use it all the
time.

> pure and native Windows Libraries and
Executables". So I guess the
> mention of Interix and Cygwin only refers to the
environment in which
> to run the toolchain, not the resulting executables?

Exactly, interix is used to run parity (which most likely is
built as an
interix executable). The resulting binaries are pure win32
(btw: 64 bit
are not supported so far...).

> 
> Anyway, for ORBit2 and code generated by its IDL
compiler, the
> interesting question is, do you have some workaround
for the object
> file format problem, i.e. something similar to GNU
ld's
> --enable-runtime-pseudo-reloc? Could this workaround
implementation be
> "extracted" from parity and perhaps used also
in a purely Visual
> Studio environment without the rest of parity?

Huh? What file format problem? I ported Orbit2 and use it
within a
somehow big application  haven't
had problems so far.

Hope that helps a little, if you have questions, i'm happy
to answer!

Cheers, Markus

> 
> --tml

_______________________________________________
orbit-list mailing list
orbit-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list