Re: "Cross-compiling for Win32" script vs. rosBE? Debian Win32 port alive?
Hi,
Several of my questions were meant to try to determine if your script
would be useful to ReactOS and/or the debian-win32 porting projects.
Your script could be useful for building for XP embedded. My interest in
ReactOS is for an embedded system too (and a few other things).
On Wed, Jun 20, 2007 at 02:33:23PM +0200, Volker Grabsch wrote:
> On Tue, Jun 19, 2007 at 11:43:38PM -0500, Drew Scott Daniels wrote:
> > How does your script for Cross-compiling for Win32 compare with rosBE?
>
> Do you mean:
> http://www.reactos.org/wiki/index.php/RosBE-step-by-step
> ?
>
> I don't know RosBE, but it semms to be more comparable with MSYS(+GnuWin32)
> or Cygwin.
>
Well most ReactOS (ros) developers build ros on Linux using mingw. I was
attempting to refer to their build environment.
> My goal is to build win32 applications from a Unix system, not from
> windows. This has several advantages over native win32 compilation,
[...]
> 2) no need to compile whole source packages
>
> When you compile a library, you don't need to build the command
> line tools, because they won't run in Unix anyway.
>
> Say, for example, that you want to cross compile libcurl. Then
> you don't need to build the "curl.exe". Just build the "libcurl.a".
>
I now understand that you meant the libraries in your environment are
created for static linking. I thought one using your environment would
be forced to create static libraries somehow, and I'm not sure that's
true. I'm not sure what the --disable-shared configure option does for
binutils.
> 3) no need to compile shared libraries (DLL files)
>
> When you port a big application to win32, you usually want to
> present one package for the windows users, that includes everything
> they need to run it. The simplest way to achieve that goal is to
> statically link all needed libraries. So you just need e.g.
> "libcurl.a". You don't need to build "libcurl.dll" and "libcurl.dll.a".
>
I maintain several applications where the use of dlls has been
considered to be a large advantage. Sharing code and reducing image size
are goals which suggest building dll's...
[...]
> If you don't, i.e. you install them system-wide to "Windows/System",
> you'd have to take care of different DLL versions, which isn't not
> possible. Windows doesn't have a suitable package system, so you're
> going to have a lot of trouble, the so-called "DLL hell".
>
"DLL hell" isn't the same as it used to be. MS has some papers about it.
As to dependency installation, well there's a few good ways to deal with
that.
[...]
> > What other alternative are out there?
>
> This question is answered in my article:
>
> http://wiki.njh.eu/Cross_Compiling_for_Win32
>
> > Does this mean the Debian win32 port is alive?
>
> No, but it may help them. I don't belong to Debian-win32, and in my
> opinion, it's nearly dead. For the above reasons, I also think that's
> the wrong way if you just want to port an application to win32.
>
Your wiki page states it's the right long term way to do it though.
> The main problem of projects like Debian-win32, MSYS and Cygwin is
> that they try to solve a big problem with a small community.
>
How big is kfreebsd? 3 very active developers are likely what's got
it in the shape it's in now. It's being considered by some for Lenny.
Cygwin's community is fairly large and was/is commercially backed.
Your script is nice. I like its simplicity. It also looks
like it'll work on other distributions. It would be nice if it could
have a minimal build environment option that'd allow more dll usage (in
the dynamic link sense), and building dlls.
[...]
> > I never considered using slind for a new architecture like win32...
> > Is the libc msvcrt? Can the libraries be dynamically linked?
>
> Please repost this question to the debian-win32 list.
>
The msvcrt question is specific to your script. debian-win32 may go
either way. Your wiki seems to indicate it's msvc based. I guess that
makes sense as porting glibc to Windows is probably still a challenge
(especially since upstream probably won't easily take it).
Libraries being dynamically linked is possible with mingw. I haven't
gone through your script in detail so I wasn't sure if this option
wasn't available. It seems like you disable this in the binutils build?
[...]
You also commented on list about file naming convention problems, and
other problems. Can you be more specific? SFU/Internix got around some
of these. Also NTFS may have some features that might help... It's
difficult for me to know without more details.
How close do your compilation sections in your script match
debian/rules for packages already in debian? Presumably it would be easy
to convert your script to pull source packages from debian instead of
the upstream sources. Ideally much of this script could be replaced by
apt-get/aptitude and Debian build scripts.
Thanks for your script and work surrounding it.
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
Reply to: