RE: Making ORBit work with MS VS compilers

["Duft Markus" <Markus Duft salomon at>]

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