Re: How to port to other UN*Xes? (was: Re: Inconsistent Architecture?)
On Wed, Oct 11, 2000 at 10:16:34PM +0200, Arthur Korn wrote:
> Another hassle is the whole gcc/automake/autoconf/make/binutils
> combo, or apache (because it really ought to be up to date). The
> time isn't that much a problem, we have a Ultra64 for compiling
> ... ;)
It seems like gcc/automake/autoconf would actually be helpful
in automating a number of things. What sorts of issues make it a
hassle for you? I know that on IRIX, gcc had a bad habit of not
working; are you encountering the same kind of problem?
On Thu, Oct 12, 2000 at 09:10:17PM +0200, Arthur Korn wrote:
> I think a first step would be to modify souce packages in a way
> so one can specify a prefix at build time (default would be
> something like /debian/$(ARCH)-$(OSNAME)$(OSREL)/
> (thinking of automounters ...).
The build-time prefix is provided by autoconf; I think
hardcoded paths are pervasive despite this. Automounters usually
handle the choice of what filesystem to mount as /usr or whatever
when you have root, so you don't need any defaults like that anyway,
except for perhaps upgrading, which is probably only a few systems.
Handling the fact that different machines might see the thing mounted
in different places is another can of worms entirely.
On Thu, Oct 12, 2000 at 09:10:17PM +0200, Arthur Korn wrote:
> We don't need to modify the entire distribution, only the whole
> working environment including development tools, editors,
> typesetters, shells and such plus the irreplaceable stuff such
> as apache, lprng, pgsql, mysql and tools like stow, top,
> fileutils, shellutils and some more. (Ok, it's allmost
> everything ... ;)
I'm not convinced that is the case; on the other hand, there are
a number of things that might make this "truer":
(1) when gcc doesn't work in an environment (try MIPS),
everything that uses nonportable C, and that's a lot of things,
will break trying to compile it with anything else.
(2) some things just aren't portable anyway, even with gcc
(3) anything that depends on /dev/, /proc/, or other kernel
features being Linux' way will break.
(4) things that aren't portable across various libraries that have
to be system supplied (X11, GL, others?) will break
(5) hardcoded paths
(6) nonportable shell scripts
(7) things that depend on the root filesystem layout
(/usr/bin/perl vs. /usr/local/bin/perl vs. /usr/local/perl/perl
etc.) will break. And believe me, there aren't a whole lot of
configure scripts that look for /usr/local/perl/perl and a lot
of stuff really wants perl to be there very badly.
These don't look _horribly_ gruesome; despite the fact there won't be
any real answer to some of these that will wipe out the problem across
all packages in one fell swoop, the important things you were talking
about probably won't be in too bad of shape, and something useful can
be done in the way of making it work in the important cases.
Cheers,
Bill
--
"The good Christian should beware of mathematicians and all those who
make empty prophecies. The danger already exists that mathematicians
have made a covenant with the devil to darken the spirit and confine man
in the bonds of Hell."
-- St. Augustine
Reply to: