Re: Online GNUstep Application Database

[Alexander Malmberg]

Damian Steer wrote:
[snip]
> > As long as you stay with single-arch binaries, you won't have any (new)
> > problems. Some distros already do this with GNUstep apps. No harder to
> > manage than normal binaries, but also no better.
> 
> No better? That seems a little unfair. GNUstep apps are nicely
> self-contained, whereas linux apps will install bits in /usr/bin,
> /usr/share/pixmaps, /usr/share/mimelnk etc. Untarring in / is not
> always desirable (or possible). (I should add that mozilla and java
> are self contained).

No better wrt packaging. As I said, I think spreading files all over the
place is a separate issue; we're better there. :)

> >> I notice that I have 'GNUSTEP_FLATTENED="yes"',
> >> but seem to recall something like fat binary support in the past (I
> >> guess flattening is the default now?). Being able to unpack and use a
> >> single .app, even if it is on the 'chubby' side, would be very
> >> nice.
> >
> > If GNUSTEP_FLATTENED is no, you get something like 'fat binaries', if
> > you can figure out a way of building them (short of manually building
> > lots of .app:s on different systems and manually assembling them).
> 
> This is really what I was asking about. Is it practical?

I don't know, but I think it could be done relatively easily if you have
a bunch of different systems you can build on. Assembly of fat .app:s
could be automated, it just hasn't been done yet (as far as I know).

It would be very nice if you could just do "make architectures={list
here}", and -make would automagically grab the right cross-compilers
(and cross-compiled libraries), but that's probably just a pipe dream.
:)

> Would the
> package need to say 'You need gui version x, back version y' etc?

Currently? Yes. -gui and -back are still too volatile; cvs versions of
apps often require cvs versions of -gui and -back. It should stabilize
eventually.

> And
> although I stated above that apps are self contained a brief survey of
> Local/Library/Libraries suggests that isn't the case for MusicBox and
> GNUMail. In which case I guess tarring a .app won't always work as
> nicely as it does on OS X.

Well, you could bug the app author about that. Arguably, apps shouldn't
install anything outside their .app bundles.

Development stuff often needs to be installed centrally, though. In
particular, libGNUMail looks like a dummy library that exists only to
get some headers installed.

[snip]
> > ldd tells you which libraries it would be linked to if you ran it now on
> > your system. Thus, it includes indirect references (like linungif, which
> > is probably linked to by -gui). To get a list of direct references, do
> > "objdump -x Foo.app/Foo" and look at the "Dynamic section" part.
>
> Ah - didn't realise it included indirect refs.

Just to make sure I was clear: ldd's output includes indirect
references. The actual binary doesn't. As long as the direct references
are satisfied, ldd will figure out the rest.

- Alexander Malmberg