Cross Compiler Unix - Windows

Cross Compiler Unix - Windows

[Ivan Novick]

Can you recommend a solution for compiling Windows DLLs on any  
variation of UNIX?

We currently do this with Cygwin/Windows, but would like to go one  
step further and do the builds on a UNIX machine that produces  
Windows DLLs.

Thanks for any advice,

Ivan

Re: Cross Compiler Unix - Windows

[Mike Stump]

On Aug 25, 2005, at 5:09 PM, Ivan Novick wrote:
> Can you recommend a solution for compiling Windows DLLs on any  
> variation of UNIX?

Yes, just use cygwin, see the cygwin folks for details.

Re: Cross Compiler Unix - Windows

[Ivan Novick]

Yes understood, but thats the whole point, cygwin runs on a windows  
machine... I would like to use a UNIX machine to compile the Windows  
DLL.

 From a system admin point of view, we would like to have a UNIX  
compile host to produce the DLL, since we primarily only deal with  
UNIX anyway.

Having a windows machine with an ssh server running as a compile host  
is less favorable than a UNIX machine with a cross compiler.

Ivan


On 26 Aug 2005, at 01:48, Mike Stump wrote:

> On Aug 25, 2005, at 5:09 PM, Ivan Novick wrote:
>
>> Can you recommend a solution for compiling Windows DLLs on any  
>> variation of UNIX?
>>
>
> Yes, just use cygwin, see the cygwin folks for details.
>

Re: Cross Compiler Unix - Windows

[Eric Christopher]

On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:

> Yes understood, but thats the whole point, cygwin runs on a windows  
> machine... I would like to use a UNIX machine to compile the  
> Windows DLL.

You can cross compile to cygwin using gcc.

An old link from google with "cross compiler cygwin" is available here:
http://www.delorie.com/howto/cygwin/cygwin-cross-howto.html

-eric

Re: Cross Compiler Unix - Windows

[Mike Stump]

On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote:
> Yes understood, but thats the whole point, cygwin runs on a windows  
> machine...

Odd, I was running it on a solaris machine not windows.  Maybe you  
forgot to recompile it on a UNIX machine?

configure --with-headers=/cygwin/usr/include --with-libs=/cygwin/usr/ 
lib target=i386-pc-cygwin && make && make install

would be an example of how I used to build one up, see the gcc  
documentation for details.  --with-sysroot or some such might be  
another way to to do it now-a-days.

> I would like to use a UNIX machine to compile the Windows DLL.

Yes.

Re: Cross Compiler Unix - Windows

[Kai Ruottu]

Mike Stump wrote:

> configure --with-headers=/cygwin/usr/include --with-libs=/cygwin/usr/ 
> lib target=i386-pc-cygwin && make && make install
> 
> would be an example of how I used to build one up, see the gcc  
> documentation for details.  --with-sysroot or some such might be  
> another way to to do it now-a-days.

  That the 'native' Cygwin GCC mimics some unexisting proprietary native
'cc' in its headers and libraries directories instead of just being only
another "C/C++/Java/Fortran/..." compiler set on Windoze, like those
GCCs for 'h8300-*', 'sh-*, 'arm-*' etc. GCCs without any GCCs on their
'native' area, has always been very weird... The same thing happens with
the 'official' MinGW GCC, it too tries to mimic some still unknown
native 'cc' !  Not even mentioning Linux and its GCC idea: "There can
be only one!", seemingly borrowed from the "Highlander" -- that all the
GCCs on a host system should use a common $prefix has seemingly been
totally unknown by the Linux people and they really expected the native
GCC to be the only GCC ever on that host! Or that if one needs more
GCCs, they can only be other versions for the native GCC...

  Platforms like Solarises, AIXes, HP-UXes, Irixes, SVR[3-5],... really
have their proprietary native 'cc's which GCC has some sane reasons to
mimic and so try to access their installed headers and libraries from
their original places. But the native-GCC will be installed into some
'local' or 'options' place, '/usr/local', '/opt/gcc' or something, where
one can add as many other GCCs as one wishes. Not to the '/usr' as has
been the rule on those "no native 'cc' seen ever here" platforms. Is
there any sane reasons for this on systems which never have had that
non-GNU native 'cc' ?

  The '--with-sysroot' tries to keep the 'proprietary' layouts even on
the cross-hosts, where people could always use the "standard install
layout for GCC", every GCC installed using just the same rules. So the
situation where all crosscompilers use their own proprietary layouts
has somehow been seen being better that trying to standardize the GCC
installation layout.

  The current cross-GCC install layout has its problems : there is only
one $target dependent place for the libraries when a typical native GCC
has at least two, '/lib' and '/usr/lib'. Meanwhile a cross-GCC has two
places for the headers: the '$tooldir/include' for the standard (posix)
headers and the '$tooldir/sys-include' for the system-specific
(non-posix etc.) headers. And maybe the last 10 years or so the GCC
developers have mixed these apples and oranges, standard and system
things, so the cross-GCC build has been a continuous mess, target
headers being searched from the 'sys-include' when the de-facto place
is the 'include' (For instance the newlib install puts the target 
headers to the 'include' and they are there when one wants to try to
build a newer GCC.) And such... If most of the native GCCs have only
the '/usr/include', the STANDARD_INCLUDE_DIR, and there is no place for
the SYSTEM_INCLUDE_DIR (please search the GCC manuals for this), is it
so hard to leave the 'sys-include' unnoticed?

  However anyone who has built more than 10 GCCs for more than 10 targets
and then installed them on the same development platform, has somehow
got used to the current (but limiting) layout, and has solved the
problems somehow. For instance what to do with the Solaris2 '/usr/lib',
'/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library
places someone recently had some problems with. And before the
'--with-sysroot' appeared at all...

  Before trying to move the proprietary layouts into the peaceful?
land of cross, it could have been better to ask the crosscompiler
builders how they have solved these "copy the target headers and
libs from the native system and put them to work with the cross-GCCs
too" problems. Maybe then there had no reason for the '--with-sysroot'.
Does it even work as one would expect it to work, solving those '/lib'
and '/usr/lib' in the 'libc.so' script problems and so on?

  Ok, as long as there are those stupid installs to '/usr' on the native
front, as long people must think how on earth the natively installed
C libraries can be copied to the cross host. Linux is a good example
about this stupidity in the very beginning. Instead of thinking how
one could produce apps for Linux easily on ANY host, it was thought
how one could produce apps for Linux ONLY on the Linux host and so
trying to make cross-compiling to Linux as hard as possible.

  Not using '--with-sysroot=' at all, but simply putting the '/lib' and
'/usr' stuff below a '$sysroot' and then symlinking the 
'$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include'
and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the
'lib' and editing the absolute paths away from the 'libc.so', enables
one to get a Linux-targeted GCC to work. With 64-bit bi-arch targets
one of course uses the default 'lib64' as the place here the
$gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the
64-bit bi-arch targets either. "It is vain to produce anything for the
idiots to follow, because idiots are so clever and always invent a
better way to do just the same thing!" (Was the '--with-sysroot' made
for people who are not as clever as we cross-GCC people who were
considered being complete idiots? :-)

  What becomes to Cygwin and MinGW, the same attitude as followed with
Linux, that "producing any apps for Windoze should happen only on
Windoze, or that when one does it on some other host, it still should
happen just like on Windoze!", is totally weird to me. My thought would
be: "Producing apps for Windoze on Windoze should happen just like it
happens on any other host, and at the same time quite in the same way
as it happens with any other GCC which is hosted on Windoze!".

Re: Cross Compiler Unix - Windows

[Mike Stump]

On Friday, August 26, 2005, at 12:59  AM, Kai Ruottu wrote:
> Is there any sane reasons for this on systems which never have had that
> non-GNU native 'cc' ?

Consistency.  This is only bad if one abhors consistency and 
predicability.  No?

I'll abstain from answering the other questions, I think they are 
better as ponder points.

RE: Cross Compiler Unix - Windows

[Dave Korn]

----Original Message----
>From: Mike Stump
>Sent: 26 August 2005 17:48

> On Friday, August 26, 2005, at 12:59  AM, Kai Ruottu wrote:
>> Is there any sane reasons for this on systems which never have had that
>> non-GNU native 'cc' ?
> 
> Consistency.  This is only bad if one abhors consistency and
> predicability.  No?
> 
> I'll abstain from answering the other questions, I think they are
> better as ponder points.

  I'll just add this observation:

>   What becomes to Cygwin and MinGW, the same attitude as followed with
> Linux, that "producing any apps for Windoze should happen only on
> Windoze, or that when one does it on some other host, it still should
> happen just like on Windoze!", is totally weird to me. 

  It seems weird to me too.  Especially considering that at least one of the
main cygwin developers builds everything on linux with a linux-x-windows
toolchain.  So perhaps you have misunderstood the situation with cygwin;
cross-development is certainly possible, and _intended_ to be possible.  It
certainly isn't any kind of policy to _deliberately_ make development only
possible on native hosts.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Cross Compiler Unix - Windows

[Nix]

On 26 Aug 2005, Kai Ruottu complained:
>                Not even mentioning Linux and its GCC idea: "There can
> be only one!", seemingly borrowed from the "Highlander" -- that all the
> GCCs on a host system should use a common $prefix has seemingly been
> totally unknown by the Linux people and they really expected the native
> GCC to be the only GCC ever on that host! Or that if one needs more
> GCCs, they can only be other versions for the native GCC...

This is nonsense. I have a dozen cross-compilers on this box, all
installed into /usr. They do not collide as long as you configure with
--enable-version-specific-runtime-libs and
--program-{prefix,suffix,transform-name} and make slight adjustments
after installation (ditch libiberty.a and some locale and manpage stuff
that doesn't get its name suitably adjusted).

There is nothing whatsoever special about the system compiler on Linux.
It's just a GCC configured with particular switches, that is all.

>   The '--with-sysroot' tries to keep the 'proprietary' layouts even on
> the cross-hosts, where people could always use the "standard install
> layout for GCC", every GCC installed using just the same rules. So the
> situation where all crosscompilers use their own proprietary layouts
> has somehow been seen being better that trying to standardize the GCC
> installation layout.

Er, GCC will always look in ${tooldir}/lib for libraries, ${tooldir)/bin
for binaries, and so on. (Your comments below indicate that you know this:
so what are you talking about here?)

>   The current cross-GCC install layout has its problems : there is only
> one $target dependent place for the libraries when a typical native GCC
> has at least two, '/lib' and '/usr/lib'.

If you are installing libgcc_s.so* into /lib, you'd better damned well
know what you're doing, as you'll be overwriting the distribution's
copy. Doing it automatically strikes me as a seriously bad idea: anyone
installing an old GCC in parallel with a new one would stand at risk of
wrecking every program on their system dynamically linked against
libgcc_s. (Those of us who don't use distributions generally have
installation-time scripts that can do the necessary by-hand mv.)

There were huge flamewars^W^Wintense debates about this when libgcc
was made into a shared library: look at the list archives.

>                                          Meanwhile a cross-GCC has two
> places for the headers: the '$tooldir/include' for the standard (posix)
> headers and the '$tooldir/sys-include' for the system-specific
> (non-posix etc.) headers.

Personally I've never quite seen the point of sys-lib and sys-include.
I just dump all the target libraries and headers into the target-
specific lib and include directories. :)

>   However anyone who has built more than 10 GCCs for more than 10 targets
> and then installed them on the same development platform, has somehow
> got used to the current (but limiting) layout, and has solved the
> problems somehow. For instance what to do with the Solaris2 '/usr/lib',
> '/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library
> places someone recently had some problems with.

I created ${tooldir}/ccs/lib et al and just had a site-config script
construct suitable -L arguments to GCC. (If you're doing much
cross-compilation you'll end up with a site-config script full of all
sorts of stuff anyway. This is nothing by comparison.)

>   Ok, as long as there are those stupid installs to '/usr' on the native
> front, as long people must think how on earth the natively installed
> C libraries can be copied to the cross host.

Er, NFS? cp? tar? All of them work.

>                                              Linux is a good example
> about this stupidity in the very beginning. Instead of thinking how
> one could produce apps for Linux easily on ANY host, it was thought
> how one could produce apps for Linux ONLY on the Linux host and so
> trying to make cross-compiling to Linux as hard as possible.

It's not hard. Just lump everything in /lib into the same place as
everything in /usr/lib on the compilation host, and everything will
work fine.

>   Not using '--with-sysroot=' at all, but simply putting the '/lib'
> and '/usr' stuff below a '$sysroot' and then symlinking the
> '$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include'
> and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the
> 'lib' and editing the absolute paths away from the 'libc.so', enables
> one to get a Linux-targeted GCC to work.

Indeed it does. (The libc.so absolute paths are... silly, but that's
not something you can blame on GCC. Best of luck convincing Ulrich
to change it.)

>                                          With 64-bit bi-arch targets
> one of course uses the default 'lib64' as the place here the
> $gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the
> 64-bit bi-arch targets either.

Yeah, but they're not really cross-compilers in that sense: they're
native compilers with extra magic (hardwired into the appropriate
backend code, no less; somewhat icky, I feel, but I can't think of a
better way to do it myself: unlike binutils, GCC just doesn't have the
generic infrastructure for multiple-simultaneous-target support, and
until *everything* is hookized is unlikely to. I imagine hookizing
everything would have another negative impact on compilation speed,
which is hardly a good thing.)


I'm not sure what you're complaining about here: your English is just
fractured enough to impair my comprehension. Is it --with-sysroot you
dislike (in which case, ditto: what's it meant for?), or is it
installing multiple parallel compilers in /usr (which works just fine)
or what?

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll

Re: Cross Compiler Unix - Windows

[Daniel Jacobowitz]

Most of this really doesn't deserve an answerr, but I'll give you a
couple anyway.  You spend a lot of time blaming people for their
opinions, without any evidence that you've actually understood their
opinions right.  Most of what I've snipped is completely untrue.

On Fri, Aug 26, 2005 at 10:59:58AM +0300, Kai Ruottu wrote:
>  The '--with-sysroot' tries to keep the 'proprietary' layouts even on
> the cross-hosts, where people could always use the "standard install
> layout for GCC", every GCC installed using just the same rules. So the
> situation where all crosscompilers use their own proprietary layouts
> has somehow been seen being better that trying to standardize the GCC
> installation layout.

No.  The point of --with-sysroot is so that you can build a native
compiler for some target, and a cross compiler to that same target, and
have them use the same layout.  The native layout is _not_ something
that we can change at this date, whatever you may like to think about
it.

>  Before trying to move the proprietary layouts into the peaceful?
> land of cross, it could have been better to ask the crosscompiler
> builders how they have solved these "copy the target headers and
> libs from the native system and put them to work with the cross-GCCs
> too" problems. Maybe then there had no reason for the '--with-sysroot'.
> Does it even work as one would expect it to work, solving those '/lib'
> and '/usr/lib' in the 'libc.so' script problems and so on?

Of course it does.  The absolute paths will be handled correctly by ld.

This was done to minimize the pain of building cross compilers to
"hosted" systems.  It seems to have worked, since everyone I've spoken
to who's used it finds it much more natural, and the process has less
undocumented voodoo than the --with-headers/--with-libs setup.

> better way to do just the same thing!" (Was the '--with-sysroot' made
> for people who are not as clever as we cross-GCC people who were
> considered being complete idiots? :-)

As one of the people who implemented this, I take offense at your
comments.  If you couldn't tell.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Cross Compiler Unix - Windows

[Andy Smith]

I have used MinGW on Linux to compile Windows
executables. I don't see why it could not be compiled
on other Unix variants. Try:

http://www.libsdl.org/extras/win32/cross/README.txt

and

http://www.mingw.org

Regards,
Andy

--- Ivan Novick <ivan.novick@makoglobal.com> wrote:

> Can you recommend a solution for compiling Windows
> DLLs on any  
> variation of UNIX?
> 
> We currently do this with Cygwin/Windows, but would
> like to go one  
> step further and do the builds on a UNIX machine
> that produces  
> Windows DLLs.
> 
> Thanks for any advice,
> 
> Ivan
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Cross Compiler Unix - Windows

[Gerald Pfeifer]

On Fri, 26 Aug 2005, Nix wrote:
> This is nonsense. I have a dozen cross-compilers on this box, all
> installed into /usr. They do not collide as long as you configure with
> --enable-version-specific-runtime-libs and
> --program-{prefix,suffix,transform-name} and make slight adjustments
> after installation (ditch libiberty.a and some locale and manpage stuff
> that doesn't get its name suitably adjusted).

mudflap is an offender as well, see Bugzilla #18244 (libmudflap
installs include/mf-runtime.h in version-independent path).

Java has libdata/pkgconfig/libgcj.pc and include/ffi.h.

And, like the man pages, the info files do not honor --program-suffix,
but for regular C, C++, Objective-C and Fortran development neither of
is a real killer, agreed.

Gerald

Re: Cross Compiler Unix - Windows

[Kai Ruottu]

Dave Korn wrote:

>>  What becomes to Cygwin and MinGW, the same attitude as followed with
>>Linux, that "producing any apps for Windoze should happen only on
>>Windoze, or that when one does it on some other host, it still should
>>happen just like on Windoze!", is totally weird to me. 
> 
>   It seems weird to me too.  Especially considering that at least one of the
> main cygwin developers builds everything on linux with a linux-x-windows
> toolchain.  So perhaps you have misunderstood the situation with cygwin;
> cross-development is certainly possible, and _intended_ to be possible.  It
> certainly isn't any kind of policy to _deliberately_ make development only
> possible on native hosts.

  Recommending Cygwin for 'ordinary users' as the preferred place for
building GNU apps for Windoze, sounds weird. Just as doing the same
with MinGW/MSYS.  The developers can have Linuces etc. better platforms
available and may require to produce everything for Linux etc. first and
for Windoze too... Only building can be enough, no very hard testing or
debugging in order to get the application to work is expected...

  This is quite the same as recommending people to build their own sport
cars from Volkswagens in garages instead of doing this in car factories
because only real Porches will be built in factories. People keep their
self-built cars there so of course these must be built there. Or 
something...

  If one wants to produce tens of binutils, GCCs etc. GNU stuff for the
Windoze host, the native Windoze shouldn't be the recommendation. Not at
least when the recommendation comes from Red Hat or from any other Linux
company. If Red Hat delivers the Cygwin tools for only the Windoze host,
what else this is than a recommendation to use Windoze instead of their
own Linux for the Windoze target development?

Re: Cross Compiler Unix - Windows

[Kai Ruottu]

Mike Stump wrote:

> On Friday, August 26, 2005, at 12:59  AM, Kai Ruottu wrote:
> 
>> Is there any sane reasons for this on systems which never have had that
>> non-GNU native 'cc' ?
> 
> Consistency.  This is only bad if one abhors consistency and 
> predicability.  No?

  I understand people coming from all kind of native cultures and
so the unified 'one culture' world seen with cross-GCCs, sounds
strange. For me the cross world is the familiar and all those native
worlds are the strange ones...

  A better approach could have been to think with every $target, how
on earth those proprietary headers & libraries could be installed
into the "standard GCC" install layout. Linux could have served as
the example for the standard GCC just as well as those GCCs which
produce stuff for Windoze.

  All the complaints about apps requiring them being built natively,
not by cross-compiling them, could have been rare. If GCC would have
had its standard search places and the stuff in these found
automatically, no need to put any

  -I/usr/X11R6/include -L/usr/X11R6/lib

like options into the GCC command line in the sources when compiling
them with GCC would have been necessary. The need for these seemingly
comes from the need to use those proprietary 'cc's to produce the same
sources.

  Ok, I don't even remember when I have needed the original native GCCs
for any builds. Maybe my repertoire is seriously limited nowadays, only
GCCs, binutils, GDB/Insights and glibcs/newlibs... If requiring to build
bash, tcsh etc. shells, whole Linux distros, maybe I would meet the
problems. But were the problems there already or has the "native only"
attitude caused them?  What if crosscompiling had been the default
everywhere?

Re: Cross Compiler Unix - Windows

[Nix]

On 29 Aug 2005, Gerald Pfeifer said:
> On Fri, 26 Aug 2005, Nix wrote:
>> --enable-version-specific-runtime-libs and
>> --program-{prefix,suffix,transform-name} and make slight adjustments
>> after installation (ditch libiberty.a and some locale and manpage stuff
>> that doesn't get its name suitably adjusted).
> 
> mudflap is an offender as well, see Bugzilla #18244 (libmudflap
> installs include/mf-runtime.h in version-independent path).
> 
> Java has libdata/pkgconfig/libgcj.pc and include/ffi.h.
> 
> And, like the man pages, the info files do not honor --program-suffix,
> but for regular C, C++, Objective-C and Fortran development neither of
> is a real killer, agreed.

Well, the man and info pages are always the same (assuming you're
installing the same GCC release targetted differently), so there's
no real problem there. The same seems to be true of libgcj.pc and
mf-runtime.h.

The ffi.h thing really is a bug with consequences: the thing's got
target-dependent contents :/

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll

Re: Cross Compiler Unix - Windows

[Mike Stump]

You do a lot of philosophizing, this list (gcc) isn't really for  
that, gnu.misc.discuss is the correct place.  Also, please pick just  
one mainline list to post to, not multiple lists.

On Aug 30, 2005, at 12:19 AM, Kai Ruottu wrote:
> Recommending Cygwin for 'ordinary users' as the preferred place for
> building GNU apps for Windoze, sounds weird.

Ordinary users don't post to gcc.  gcc is the list for the  
development of gcc, and for power users that want to ask really  
obscure tricky questions.  :-)

If you don't like the advice, you are free to ignore it.

> This is quite the same as recommending people to build their own sport
> cars from Volkswagens in garages instead of doing this in car  
> factories
> because only real Porches will be built in factories.

Agreed.  Welcome to the build-it-yourself, self-help group.  If you  
want a factory show-room floor, this ain't it.  My mind is so limited  
I just cannot grasp your point above.  Is your point that you wanted  
us to tell you were the new car dealer is?

> If one wants to produce tens of binutils, GCCs etc. GNU stuff for the
> Windoze host, the native Windoze shouldn't be the recommendation.

I don't recall anyone recommending a native Windows anything in this  
thread.

> Not at least when the recommendation comes from Red Hat

This list isn't for discussing what Red Hat may, or may not recommend.

> or from any other Linux company. If Red Hat delivers the Cygwin  
> tools for only the Windoze host, what else this is than a  
> recommendation to use Windoze instead of their own Linux for the  
> Windoze target development?

Reality, customer choice, free market, pick one, or two, or three.

Re: Cross Compiler Unix - Windows

[Mike Stump]

On Aug 30, 2005, at 12:42 AM, Kai Ruottu wrote:
>  I understand people coming from all kind of native cultures and
> so the unified 'one culture' world seen with cross-GCCs, sounds
> strange. For me the cross world is the familiar

Apparently not, as you didn't just build up a compiler and use it.

> and all those native worlds are the strange ones...

You seem awfully hung up on native cygwin, a topic no one but you  
even mentioned.  Why did you bring it up?

> A better approach could have been to think with every $target, how
> on earth those proprietary headers & libraries could be installed
> into the "standard GCC" install layout.

We welcome your patch to implement this.

> All the complaints about apps requiring them being built natively,
> not by cross-compiling them, could have been rare.

We welcome your patch to fix this.

Re: Cross Compiler Unix - Windows

[Christopher Faylor]

On Tue, Aug 30, 2005 at 11:58:24AM -0700, Mike Stump wrote:
>On Aug 30, 2005, at 12:42 AM, Kai Ruottu wrote:
>> I understand people coming from all kind of native cultures and
>>so the unified 'one culture' world seen with cross-GCCs, sounds
>>strange. For me the cross world is the familiar
>
>Apparently not, as you didn't just build up a compiler and use it.
>
>>and all those native worlds are the strange ones...
>
>You seem awfully hung up on native cygwin, a topic no one but you  
>even mentioned.  Why did you bring it up?

Yeah, and it's native cygwin which has a layout which tries very hard to
mimic a standard UNIX layout for what should be extremely obvious reasons.

cgf

Re: Cross Compiler Unix - Windows

[Christopher Faylor]

On Tue, Aug 30, 2005 at 10:19:36AM +0300, Kai Ruottu wrote:
>Dave Korn wrote:
>>>What becomes to Cygwin and MinGW, the same attitude as followed with
>>>Linux, that "producing any apps for Windoze should happen only on
>>>Windoze, or that when one does it on some other host, it still should
>>>happen just like on Windoze!", is totally weird to me.
>>
>>It seems weird to me too.  Especially considering that at least one of
>>the main cygwin developers builds everything on linux with a
>>linux-x-windows toolchain.  So perhaps you have misunderstood the
>>situation with cygwin; cross-development is certainly possible, and
>>_intended_ to be possible.  It certainly isn't any kind of policy to
>>_deliberately_ make development only possible on native hosts.
>
>Recommending Cygwin for 'ordinary users' as the preferred place for
>building GNU apps for Windoze, sounds weird.  Just as doing the same
>with MinGW/MSYS.  The developers can have Linuces etc.  better
>platforms available and may require to produce everything for Linux
>etc.  first and for Windoze too...  Only building can be enough, no
>very hard testing or debugging in order to get the application to work
>is expected...

So, you think that when people need to build windows apps, the
"recommendation" should be that people should buy a linux box, put their
sources on the linux box, figure out where to get or how to build a
cross compiler, build the sources, and then figure out how to transfer
the sources to the windows platform.

The alternative is to install Cygwin or MSYS and then just build your
sources without worrying about linux, cross compilers, or how to transfer
software to/from windows.

Ever heard of Occam's razor?

>This is quite the same as recommending people to build their own sport
>cars from Volkswagens in garages instead of doing this in car factories
>because only real Porches will be built in factories.  People keep
>their self-built cars there so of course these must be built there.  Or
>something...

I have no idea what this analogy is trying to say but, again, recommending
to people that they go out of their way not to build on the platform that
they are targetting is clearly not the most straightforward or foolproof
plan.

>If one wants to produce tens of binutils, GCCs etc.  GNU stuff for the
>Windoze host, the native Windoze shouldn't be the recommendation.  Not
>at least when the recommendation comes from Red Hat or from any other
>Linux company.  If Red Hat delivers the Cygwin tools for only the
>Windoze host, what else this is than a recommendation to use Windoze
>instead of their own Linux for the Windoze target development?

Huh?  What does "Red Hat" have to do with anything?  "Red Hat" doesn't
provide the tools.  Cygwin is a volunteer effort.  The fact that you can
build cross compilers from some other system to windows doesn't mean
that Cygwin is at fault for not providing the cross compilers.  The
whole *point* of Cygwin is to provide a linux-like environment for
Windows.

The fact that I do build the cygwin release on linux doesn't mean that
I'd recommend doing this to every person who wants to compile stuff for
Windows.
--
Christopher Faylor			spammer? ->	aaaspam@sourceware.org
Cygwin Co-Project Leader				aaaspam@duffek.com
TimeSys, Inc.

Re: Cross Compiler Unix - Windows

[Ivan Novick]

> So, you think that when people need to build windows apps, the
> "recommendation" should be that people should buy a linux box, put  
> their
> sources on the linux box, figure out where to get or how to build a
> cross compiler, build the sources, and then figure out how to transfer
> the sources to the windows platform.
>
> The alternative is to install Cygwin or MSYS and then just build your
> sources without worrying about linux, cross compilers, or how to  
> transfer
> software to/from windows.
>

As the person who started this thread over 2 weeks ago, hopefully the  
thread can end here...

The original question was asked because we are mostly a UNIX house  
and want to use Windows as little as possible...

Hence the question "is it possible to build a Windows DLL without  
Windows at all" ...

We currently use Cygwin for this which works just fine... but from  
our perspective the less Windows the better ...

Thanks all for the helpful replies.

Ivan

Re: Cross Compiler Unix - Windows

[Gerald Pfeifer]

On Tue, 30 Aug 2005, Nix wrote:
>> mudflap is an offender as well, see Bugzilla #18244 (libmudflap
>> installs include/mf-runtime.h in version-independent path).
>> 
>> Java has libdata/pkgconfig/libgcj.pc and include/ffi.h.
>> 
>> And, like the man pages, the info files do not honor --program-suffix,
>> but for regular C, C++, Objective-C and Fortran development neither of
>> is a real killer, agreed.
> The ffi.h thing really is a bug with consequences: the thing's got
> target-dependent contents :/

This is now Bugzilla java/23935 ($PREFIX/include/ffi.h needs to go to a 
target- and -version-dependent location), in case someone knowledgeable
wants to have a look.

Gerald

Re: Cross Compiler Unix - Windows

[Gerald Pfeifer]

On Fri, 2 Sep 2005, Christopher Faylor wrote:
> Huh?  What does "Red Hat" have to do with anything?  "Red Hat" doesn't
> provide the tools.  Cygwin is a volunteer effort.

According to http://cygwin.com/license.html (and the link from there)
Red Hat does provide tools for some set of users at least:

  Red Hat sells a special Cygwin License for customers who are unable to 
  provide their application in open source code form. For more 
  information, please see: http://www.redhat.com/software/cygwin/

Gerald

Re: Cross Compiler Unix - Windows

[Christopher Faylor]

WHY are you resurrecting this discussion?

On Mon, Sep 19, 2005 at 03:30:37PM +0200, Gerald Pfeifer wrote (after a 2+ week delay):
>On Fri, 2 Sep 2005, Christopher Faylor wrote:
>>Huh?  What does "Red Hat" have to do with anything?  "Red Hat" doesn't
>>provide the tools.  Cygwin is a volunteer effort.
>
>According to http://cygwin.com/license.html (and the link from there)
>Red Hat does provide tools for some set of users at least:
>
>Red Hat sells a special Cygwin License for customers who are unable to
>provide their application in open source code form.  For more
>information, please see: http://www.redhat.com/software/cygwin/

Uh, yeah.  I wonder who wrote those words.

Ok.  Yes.  Red Hat does sporadically and half-heartedly sell the Cygwin
tools.  However no one, prior to this had mentioned Red Hat.  We're in a
free-software forum which was talking about Cygwin so the correct
supposition is that we're not talking to the 2 Red Hat Cygwin customers
here.  We're talking to people who have accessed Cygwin via the
cygwin.com web site.  That site is maintained by volunteers (mainly me).
The software is provided free of charge from the cygwin site, not by
Red Hat, like any other free software project out there.

Conflating Red Hat policy with the free software distribution used by
99.9999999999% of cygwin users is not useful.

cgf