Re: non-Linux OSes


On 21/10/13 10:34, Ryan Lortie wrote:

GLib aims to work on a wide range of operating systems, but we have no
good story for ensuring that this is the case.  Mostly we do things for
Linux and, if they are the sort of thing that may cause problems, we
also check that they work on Windows.  We read manpages and make sure
that the functions we are using are in the proper POSIX specs, but this
is not always a fool-proof process.

We want to improve this situation.

Dan recently started by doing some patches to pull out ancient support
for OSes like OS/2 and BeOS.

We have brainstormed a list of platforms that we think that we want to
support and it looks like so:  Linux, {Free,Net,Open}BSD,
(Open?)Solaris, HP-UX, AIX, Hurd, Darwin, mingw(32/64), MSVC.

There is also the question of non-standard compilers (icc?).

What we don't have are the resources to setup routine testing of GLib
against these target operating systems.  Some of these operating systems
are not Free Software.

What would be nice is if we could gain access to some machines (from
various projects) that we could use for testing GLib and/or if we could
get a VM farm setup on GNOME infra that various projects would help us
to setup (and maintain) their OSes on.

I don't have any concrete ideas here, but it seems like there are some
good options.  If anyone has ideas or offers of help, they are greatly

In Debian we build glib for several architectures (including x86, amd64,
armel/armhf, ppc, sparc...), for GNU/kFreeBSD on amd64 and x86, and for GNU/Hurd
on x86. We currently run the testsuite only on linux (and we make test suite
failures cause the build to fail).

We try to build development snapshots in experimental (though right now 2.38 is
there as we haven't had the time to fix the regressions and upload to

Build logs/status can be checked from:

Even more 'unofficial' architectures are available from

As you can see 2.36 successfully ran the tests on all those 11 linux
architectures. 2.38 needs a bit of work but I haven't had the time to look at it
yet. Help there is more than welcome! (Note that sometimes test failures are
just race conditions because the tests run on loaded/slow machines).

If a developer needs/wants access to a box for any of those architectures for
the purposes of debugging/fixing some GNOME software I may be able to help on a
case-by-case basis.

Note that we try to do the same thing (run the testsuite, make test failures
fatal) for other GNOME packages, so this doesn't just apply to glib.

Hope this helps.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]