libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] GNU/kOpenSolaris port


From: Robert Millan
Subject: Re: [PATCH] GNU/kOpenSolaris port
Date: Tue, 30 Dec 2008 01:22:15 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, Dec 29, 2008 at 11:40:55PM +0100, Ralf Wildenhues wrote:
> 
> I think the patch is mostly ok, but some details matter: you are not
> adjusting _LT_ENABLE_LOCK, which probably means $LD is not getting an
> appropriate '-m $emul' flag set, right?

This only appears to be an issue for biarch arches like x86_64, powerpc
or s390, am I right?   Note that this port is i386 only for now.

> Secondly, at a glance I don't see support for your system's canonical
> name in config.guess/config.sub.  Have you already sent a patch to the
> address@hidden address for that?

I'm afraid it was rejected.  The config maintainer has changed his policy and
is now very strict about assigning new triplets.  He requires a fully
featured system with a user community, etc.

And I suppose you understand that libtool support is essential before we can
consider archieving this goal.

> This matters because while matching *-gnu might be the right thing for
> all systems with glibc, the ordering in the file may matter in that we
> shouldn't by accident have some other case branch that matches it
> earlier (this is mostly so we don't regress accidentally in the future).

We're using 'i386-pc-kopensolaris-gnu' as triplet.  I don't think it's
likely that we match anything else by accident.

As for non-glibc systems matching *-gnu, I verified (by inspecting
config.guess) that the only possibilities are:

  - Linux-based systems (not a problem since you're matching them in the
    same checks anyway).

  - The old non-glibc Debian GNU/NetBSD port.  I believe it is now defunct
    (I can confirm if you like), but even if it's not, it'd be possible
    to keep it happy by matching it before the generic *-gnu test.

Thanks!

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]