Re: "Cross-compiling for Win32" script vs. rosBE? Debian Win32 port alive?
On Fri, Jun 22, 2007 at 11:44:33AM +0200, Volker Grabsch wrote:
> On Fri, Jun 22, 2007 at 01:05:17AM -0500, Drew Scott Daniels wrote:
[...]
> > 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).
>
> That sounds interesting, although I personally would go away from
> Windows *especially* on embedded devices. ;-)
>
> Why do you need XP on those devices?
>
At least one difficult to port MFC application (thousands of lines of
code, many Windows specific functions, type size/order assumptions, file
name case inconsistencies...).
In another case, I don't want to/can't port the Windows drivers to
Linux. Some binary applications may also become a problem for me on wine.
> > > > How does your script for Cross-compiling for Win32 compare with rosBE?
> [...]
> > Well most ReactOS (ros) developers build ros on Linux using mingw. I was
> > attempting to refer to their build environment.
>
> What exact is is their Linux MinGW build environment? Does everyone
> create his/her own cross compiling environment?
>
Initially everyone created their own cross compiling environment. I
think sometimes there's been some tarballs... There used to be step by
step instructions iirc.
[...]
> Maybe the ReactOS developer work differently, but except for some
> superfluous cross-compiling howtos, I never found a real documentation
> of how to cross compile a bunch of libs with MinGW.
>
ReactOS is different though. They don't try to cross compile Linux
libraries (well maybe some). They use MS Windows like libraries. MFC,
win32, msvcr... quite a bit of the user space code they use is from the
wine project. These libraries provide quite a bit of functionality,
likely duplicating a good portion (if not all of) some of the libraries
you're porting. That said, these are targeted at a different audience,
and their project doesn't need many of the apps/libraries that many
Linux developers want.
ReactOS uses svn, bugzilla, irc, mailing lists and web forums. The
community seems to be much more organised than GnuWin32.
[...]
> However, it's sometimes hard to force one package to use the static
> instead of the dynamic variant of a library. Such mistakes are subtle
> and sometimes very hard to find.
>
Any examples? I haven't tried.
[...]
> > 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...
[...]
> I'm curious: What applications to you ship?
>
> If you are shipping e.g. many binaries that use a common code base
> it might be a good idea to put everything they have in common statically
> into one library. Then build this library as DLL, and link your binaries
> against it. This way, all binaries will be very small, and you have only
> one (big) DLL to ship, instead of 10 or 20.
>
I use delayed loaded dll's, and don't always load them all. There's also
a dependency tree between the dlls. This is for a single application.
Besides that, there's separate distributions of applications that may
use some of the common code that are just easier to leave dll's rather
than mucking with the project settings. I am now tempted to look at how
to best setup the MSVS builds to do both .libs and dlls.
[...]
> > > 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.
>
> Is there? Even when you want backwards compatibility to Win98, WinME,
> etc.?
>
Well, it was a concern for those OS's but not as easy to deal with. If
you're interested, you'd have to learn the dll load paths and
versioning. It's been much improved in recent OS releases. I don't care
enough about it myself, and I suspect most other developers are the
same. I just want things to work and thus would be inclined towards
static compilation of some libraries. That said, I think it can cause
bloat when widely used on a system.
> Anyway: I'm very intrested in the way you manage your packages. It
> sounds interesting.
>
Drag all the non-core dependencies for many projects of mine. Larger
projects can use msi dependencies etc.. Cygwin has their own dep model
(something in setup.exe's configuration file I think). You know about
the apt port.
Well, I must admit most projects drag all their non-core dependencies
with them out of convenience. VLC on win95 requires several packages
that can be easily found, although it seemingly must be done manually.
Win9x would typically tell you what was missing, later versions
sometimes would not (see SxS AKA side by side errors and their event log
messages). Additionally one can sometimes use dependency walker to
manually find dependencies. Some other examples are OpenOffice.org and
JRE, Games with DirectX, wireshark and winpcap, .Net applications & the
.Net API (though I've learned this can easily be mishandled).
[...]
> > > > Does this mean the Debian win32 port is alive?
[...]
> > Your wiki page states it's the right long term way to do it though.
>
> Well, that's not entirely correct. It's the right long term way to
> use the Debian sources for creating cross-compiling win32 binaries.
>
> However, I'm not sure whether it's a good way to build binary packages
> for a "win32" architecture an then convert them via dpkg-cross.
>
I suppose native compilation would be a better approach for win32.
> There *could* be a Debian-win32 distribution, but there isn't. Those
> compatibility patches *could* be included in the Debian source
> packages, but their maintainers refuse them for a good reason: Many
> cludges and different filenames. They don't want to bloat their
> debian/rules files and they don't want to have different variants of
> "package.files".
>
I'm doubtful I'd have time to create the diffs and file the wishlist
bugs. I'm sure some maintainers would be interested though.
> So one has to maintain an own debian/rules or at least some patches
> for the debian/ directory that won't ever be included in Debian. One
> has to build every package as "native win32" that aren't usable to
> anyone (because there's no real Debian-win32 distribution). In the
> end, one converts all of them via dpkg-cross which leaves packages
> that are only useful for Debian developers.
>
native win32 applications are useful on win32 systems like ReactOS, and
MS Windows.
> Such a system is not only hard to create but also hard to maintain!
>
Yes. I'm worried about ReactOS collapsing or even just regressing.
> It would be different if one would just need some simple compatibility-
> patches to the debian/rules. It would be different if the created
> win32-arch-binaries were usable for some Windows distribution. It would
> be different if Windows had a good package system with handles dependency
> conflicts and the like. If would be different if most of the win32 cross
> developer were using Debian.
>
How about win32 developers using kReactOS Debian distribution? Could
happen.
> But all that isn't the case. So it's just a lot of extra-work without
> any benefits.
>
If you have time, file wishlist patches against some of the Debian
packages please. You may be able to simplify your script in the future
by making use of debian/rules files. You might even consider asking for
some of the build options to become easier to use via upstreams.
[...]
> 3 active developers, all FreeBSD users? Well, I'd be happy to have
> just a *second* helping person, no matter what unix system he/she
> uses. If there were 3 Debian developers working on a mingw cross
> compiling environment, the situation would be totally different. But
> obviously, there isn't.
>
kfreebsd, not FreeBSD. See debian-bsd, or the BSD port info. I think two
of the kfreebsd developers are not Debian developers (one retired, but
still helps with the port).
ReactOS may be interested in a subset of your script. They don't pull in
very many build dependencies.
[...]
> > I guess that
> > makes sense as porting glibc to Windows is probably still a challenge
> > (especially since upstream probably won't easily take it).
>
> As far as I know, the advantage isn't big enough. If you want to create
> a win32 software distribution, it might be. But if you just want to
> cross compile some bigger applications, msvc-based cross compiler is
> definitely the way to go.
>
Does mingw or any project other than cygwin have glibc for Windows?
[...]
> > You also commented on list about file naming convention problems, and
> > other problems. Can you be more specific?
>
> The simplest example: libSDL. On unix, you have:
>
> dev:
> /usr/libSDL.a
> /usr/libSDL.la
>
> runtime:
> /usr/libSDL.so*
>
> On win32, you have:
>
> dev:
> /usr/libSDL.a
> /usr/libSDL.la
> /usr/libSDL.dll.a
>
> runtime:
> /usr/libSDL.dll
>
> It's not a big difference. But it *is* a difference, in contrast to
> all POSIX systems. And that's the annoying fact.
>
> > SFU/Internix got around some
> > of these. Also NTFS may have some features that might help...
>
> That sounds interesting.
>
Ask in ros-dev if you're interested. I'm not sure if it was just
kludges, or if there's a way to make the system accept the POSIX names.
microsoft.public's services for unix newsgroup may be helpful to figure
some of this out.
[...]
> I'd help you and give some advice. But don't expect me to do all
> the work. I tried, I got no help [1], I choke on the amount of
> work and useless complexity, and I failed. That's the reason I
> wrote that simple script instead. Partly because it's practical,
> but also to demonstrate how easy all this could have been...
>
> With my script, I didn't even need to ask for help, I just got it
> offered from some people. I think, this has several reasons:
[...]
I understand your approach, and I think it was the right one for you.
It's definitely a help with getting GNU/Unix/Linux tools onto win32.
My wishlist for your script includes:
- Pulling from debian source packages instead of upstreams (different
URLs, fewer versions available, some versions might be removed more
quickly). Having some of the Debian patches may be useful. Using
Debian packages also encourages the community to maintain things in
Debian where there are usually more long term releases.
- Optional pulling with apt (makes source cd's and other apt advantages
available. E.g. apt-cache)
- making use of debian/watch files to find new upstream source (see also
dehs). This may not make sense as it can be risky to upgrade.
- Trying to use debian/rules when possible (sounds like almost never)
- Making it easier to use dll versions of the libraries (although I'm
not sure it makes sense for any libraries you're using)
- A native win32 version (no changes? might just require some mingw like
packages like bash, curl?... to run the script and its commands)
- ReactOS build environment creation (certain gcc & binutil packages
won't work). This env would require limiting to certain versions of
code, and should probably not pull in extra libraries.
- Making more libraries available
I suppose the phrase is "patches welcome" for me, but I thought I'd
share my wishes anyways in case some are quick/easy for you/others.
There's also a slight chance I'll look back at this message and do some
work on this.
Thanks,
Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html
Reply to: