[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: solaris 10: address@hidden
Re: solaris 10: address@hidden
Mon, 4 Jul 2005 15:21:30 +0100 (BST)
On Wed, 29 Jun 2005, Ralf Wildenhues wrote:
* David Lee wrote on Tue, Jun 28, 2005 at 07:10:59PM CEST:
(Incidentally: this may or may not be relevant to the above: in my own
case, I know that our GNU ld and libtool are somewhat out-of-date. So
I've attempted to get libtool 1.5.18 installed. "make check" is fine on
S8, but has a failure in "mdemo2-make.test" on S10. If someone can guide
me, I'd be happy to try to pursue this futher.)
I bet this is related, it tests dlopening.
make check VERBOSE=x TESTS='mdemo-conf.test mdemo-make.test mdemo2-conf.test
and post the output (This is a subset of the check above).
(See earlier email for that output. Also, Ralf and I had a very useful
off-list email chat. I think it is now time to come back on-list.)
Over the weekend, someone on the Sun forum:
dug a little deeper with their applications, indicating that a generated
setting "build_libtool_need_lc=yes" may be problematical on S10. Setting
it to "no" seemed to improve things. So I have tried something similar on
my application (heartbeat, a.k.a. linux-ha) which also seems to look
I should probably now try this on libtool-1.5.18 and its similar failure
on S10 in "mdemo2-make.test", but don't know the best way to do this, so
am looking for some guidance.
The basic idea of the fix (workaround, fudge) is to try to strip out all
traces of "-lc" and "-ldl" when building shared objects (".so").
Now I don't the insides of libtool at all (not in the slightest!). So
what follows is supposition.
I suspect that the problematic code is in "mdemo2/acinclude.m4" around
AC_MSG_CHECKING([whether -lc should be explicitly linked in])
which is generating a "yes", which I then think becomes the value of
variable "build_libtool_need_lc" in the generated "libtool".
I think there is some overloading happening, with this result being used
in two different contexts which may require different values. This code
(mdemo2/acinclude.m4:6000) is using the result of linking a final,
runnable progam (which probably _does_ need "-lc" and/or "-ldl") to set a
"yes" (probably needed for final programs). But that result also seems to
be used for linking shared-objects (".so"), and it seems that (for reasons
yet unknown) this probably should _not_ be done for S10 (fine on earlier
Does that seem plausible?
Could someone who knows libtool possibly suggest some possible experiments
(e.g. edits, pseudo-patches) that I, a complete novice to libtool
internals, might try? Do we need an additional variable alongside that
"build_libtool_need_lc", to indicate how to build shared-objects?
I'm using GNU/ld; but I'd be happy,as part of the experiments, to try to
redirect our "gcc" to use the Solaris/ld. (How to redirect it?)
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
- Re: solaris 10: address@hidden,
David Lee <=