Re: "Cross-compiling for Win32" script vs. rosBE? Debian Win32 port alive?
On Sat, Jun 23, 2007 at 12:25:42AM -0500, Drew Scott Daniels wrote:
> 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.
Are you sure? Even if it did - wouldn't it be more sensible to write
software that uses a cross-platform library like "libpng" than some
"natively" available PNG support?
The libraries I'm porting are not "unix libraries", they are cross
platform libraries, often better suited for their task than any OS
specific library. Compare e.g. writing a 2D game with libSDL and
DirectX. Writing it with libSDL ist easier, more fun and you get
portability. Same for libcURL, GD, etc.
> 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 may be interested in a subset of your script. They don't pull in
> very many build dependencies.
Don't hesitate to start a fork, maybe reusing the general structure
of the script, throwing out all libraries you don't need, and put
in the libs you want. Those new libs, in turn, I could add to my
script.
I'm currently even doing it myself! For development purposes, I have
a smaller variant of the script that contains all new libraries I'm
trying to get working. This new script unpacks the mingw_cross_env.tar.gz
(created by the original script) to have a clean startup. Then it builds
the experimental libs. This way I can test and fix new build instructions
relatively quickly before I put them into the big script and run a final
test.
> > 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.
Just try, you will be "forced" to make that experience. Compile e.g.
libpng statically and as DLL. Then compile an application that uses
libpng. It will automatically use the DLL variant, and you'll have to
do some tweaks to force it to statically link to libpng. The easiest
way, by far, is not to build libpng.dll in the first place. :-)
Now a more subtle example: LibGD is a generic graphics library that
internally uses libpng, libjpeg, etc. It's kind of common API to those
libs. Now suppose you build libpng as DLL and static. Same with LibGD.
Now you build your app which will then need the libgd.dll. Suppose you
don't like that, so you make some tweaks and you link libGD statically
into you app. Boing! Your app will still depend on libpng.dll, because
even the static libGD variant has been dynamically linked to libpng.
I hope, those simple examples make things clear. Now imagine the fun
of doing that with 10 libraries. You should consequently use either
many small DLLs or one big DLL (or one big EXE). Mixing up is not a
good idea. You should make that decision at the beginning, just to
decide which library to build as static *.a and which as DLL. If you
do this consequently from the beginning, you'll have muss less trouble.
> > 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.
[...]
> 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).
That's an interesting point: If you don't need to support older Windows
versions, and want a good dependency / DLL handling, why don't you just
use .NET?
.NET is especially interesting in concerns of portability, because you
can use Mono, develop with Mono on Linux, and "porting" to Win32 consists
of just copying the *.exe file over. Well, you may also need some
Mono-DLLs, but those you can freely distribute with your app.
The only bad thing with Mono/.NET is the GUI library "WinForms".
However, GTK has been ported to Mono (called GTK#), so you just add
some more DLLs and get a good GUI library.
So Mono is a very interesting option for win32 cross compiling, if
you are starting a new project and don't want to support older
Windows versions.
> > 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.
For projects like ReactOS: Yes.
For single applications that want to provide a Win32 version: No.
On Debian we have a MinGW cross compiler, NSIS and UPX. If you add
the cross compiled libraries, you everything you need to produce
a win32 installer .exe entirely from your Linux system. And in fact,
I've already done that for some projects. Tower Toppler
(http://toppler.sf.net/) is a good example.
> > 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.
Yes, and if that happened, they would be the critical mass needed to
initiate that progress, and I'd be happy to support that movement.
However, it's impossible for me to start that movement, because I'm
not interested in "kReactOS Debian" in any way.
At the moment, the only community I'm getting help from is the
"community" of win32 cross developers which develop on various Linux
and *BSD systems. Of course, "our" community and the "kReactOS Debian"
community can and should help each other. My script is a first step.
Supporting Debian sources may be the next one. But I will not make
that effort for an imaginary community that currently consists of
exactly 0 people. I already wasted too much time for such projects.
I'd be happy to support that community, if your "Could happen." really
happens some day.
> > 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.
Currently, that would make things more complicated.
> You might even consider asking for
> some of the build options to become easier to use via upstreams.
That kind of patches is called "dpkg-cross compatibility" and I
already brought some of those patches into the packages. However,
my patches were only partly accepted - mainly the use of CROSS*
variables. Other parts of those patches like handling DLL files
were rejected, and with hindsight I think it was the right decision
of the maintainers. Any Debian-win32 distribution should have
compatible directory structures and file naming schemas before it
can expect a wider acceptance from the various package maintainers.
> 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.
The Debian patches are very interesting, the debian/rules aren't.
That's currently my dilemma. Adjusting the existing debian/rules
is more work than writing own ones, even when they're using cdbs.
And even easier than writing an own debian/rules is to just put
the build commands into my script. ;-)
However, the debian/rules files are a good insiration. For example, I've
taken a look at the debian/rules of "mingw32" and "smpeg" while writing
my script.
> - Optional pulling with apt (makes source cd's and other apt advantages
> available. E.g. apt-cache)
This would add complexity without a suitable benefit, because the
script has already its own "cache", i.e. the download/ directory.
> - 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.
The debian/watch mechanism is only slightly better than the
portable "curl | sed" variant my script currently uses.
> - Trying to use debian/rules when possible (sounds like almost never)
See above. IMHO that doesn't make any sense.
> - Making it easier to use dll versions of the libraries (although I'm
> not sure it makes sense for any libraries you're using)
Just replace
--disable-shared
with
--disable-static
on any library you like to link dynamically.
> - A native win32 version (no changes? might just require some mingw like
> packages like bash, curl?... to run the script and its commands)
Initially, the script was designed to run on MSYS as well. This fails
for two reasons:
1) My script uses wget consequently, but could be easily rewritten
to use curl instead. However, MSYS has neither wget nor curl.
2) Some libraries need additional build tools like perl and python,
even when you "./configure --disable..." any perl/python stuff.
Problem 1) can be solved by providing a full download/ directory, or
by installing wget into your wget environment.
Problem 2), however, requires more work. It could work if you install
those extra tools as well. But in that case you might want to simply
use Cygwin instead. I didn't test my script in MSYS, an I don't think
it's worth the work. One important part of my concept is to use the
already avaiable unix tools instead of having to build them, too.
> - 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.
I don't know what that means exactly, as I don't work with ReactOS.
I'm not qualified for that job, but I offer you my help when you want
to try this.
> - Making more libraries available
That's everyone's wish. ;-)
> 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.
Sorry, but most of your wishes are I had to reject for practical reasons.
Simplicity, portability and transparency are the big strengs of the
script, I don't want to endanger them without real benefits.
However, two things remain feasible:
a) adding new libs
(for ReactOS or others)
b) using Debian sources and patches
For a), just be more concrete. What libs do you need? Maybe I'll work
on some of them. I got library-wishlists from other people as well.
For b), we need more: We need to work on a good concept. I told you some
of the problems, maybe you have some good ideas.
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Reply to: