[Top][All Lists]

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

Re: ncurses-5.6 build problems on Darwin/MacOSX

From: Thomas Dickey
Subject: Re: ncurses-5.6 build problems on Darwin/MacOSX
Date: Thu, 28 Dec 2006 20:56:32 -0500
User-agent: Mutt/1.5.13 (2006-08-11)

On Thu, Dec 28, 2006 at 11:58:13AM -0600, address@hidden wrote:
> Hi,
> The last good compile & install I have is with
> ncurses-5.5-20061104.patch.

I'm puzzled, since none of the configure-script changes that I would
suspect were changed after that point.  The biggest change after that
is the change in the test-compile/run to use "return" rather than
"exit".  But the libtool test is just scripts - no compiles.  The
relatively recent change to use curly-braces in makefiles (to allow
using the same tokens in scripts and makefiles) would be where I'd
first look.  That was done in 20061014.

Running your options, and setting
to force it to run the "same" configure, I only see a few real differences
(other than the curly-braces/parentheses) in the resulting Makefile's.
> The current ncurses-5.6 with ncurses-5.6-20061223.patch.gz is
> having problems here.  I don't have the 'nads to try later patches
> on ncurses-5.5 until I can get help figuring out what happened to
> libtool support since 20061104, please.

> --with-libtool=/usr/local/bin/glibtool \
> --with-build-ldflags="${LDFLAGS} -Wl,-search_paths_first " \

I'm puzzled by this one (it would be used if you're cross-compiling).

> checking if you want to build libraries with libtool... 
> /usr/local/bin/glibtool
> checking version of libtool... 
> configure: error: This is not libtool
> [~/Projects/ncurses-5.6]root# _
> <<<<
> Here's the config.log from this run:
> configure:3845: checking if you have specified an install-prefix
> configure:3858: result: 

I'd see what's going on in the configure script by going to line 4030,
and adding a
        set -x

> configure:4030: checking if you want to build libraries with libtool
> configure:4040: result: /usr/local/bin/glibtool
> configure:4133: checking version of libtool
> configure:4140: result: 
> configure:4143: error: This is not libtool
> ## ----------------- ##
> ## Cache variables.  ##
> ## ----------------- ##

> cf_cv_libtool_version=

All I can see right now is that the result is empty - perhaps because
the form of the version's changed.  I don't _see_ where I've changed
anything that would break this...

> Apple's /usr/bin/libtool is not really GNU's, instead I mimicked
> Fink's way of building & installing GNU's latest libtool-1.5.23a
> which has some desperately needed fixes for Darwin etc.  N.B. I
> did not use Fink to install libtool, I used its tricks of renaming
> libtool[ize]->glibtool[ize] so not to step on Apple's, otherwise
> the libtool build was a plain ./configure - make - make install .
> Then used ncurses-5.5 configure parms just as shown above and
> everything there seems to work quite nicely.
> As you can see above, tho, ncurses-5.6 does not like this anymore.
> If I drop that parm for ncurses-5.6 configure, later on at install
> time we get some nasty problems of relinking libtinfo & libncurses
> whilst the shell and readline-5.2 libs all need it available.
> There is no way to work-around this with Apple's DYLD_LIBRARY_PATH
> without causing Apple-loader problems saying the installed lib is
> not at a current level and all that jazz.
> AFAICT, with ncurses-5.6 not configured to use libtool: when the
> make-install is relinking libtinfo or libncurses for installation
> into the "hot" /usr/local paths, there is a window in the make
> scripts that apparently call the shell or other tools, and those
> in turn need libreadline or others that depend on the libtinfo /

hmm - I hadn't considered this (since "no one" uses rpath for things
that would break the shell ;-).

> libncurses, but the symlink for the "short" libname has not been
> done yet (the old symlink has already been deleted), so you see
> the round-robin problem we have here.  I can't even create a
> "short" libname with chmod 000 to "keep" it there during the
> meantime, the make-install script still deletes it, which is as
> noted then gone for the next step in the make-install script.

The change that you seem to be describing is still mid-October,
rather than the beginning of November...

But --with-rpath is redundant (for the cases I know of, since libtool
walks all over that area).
> Supposedly the libtool-1.5.23a (renamed to glibtool[ize] as
> needed) can do the make-install in a better way as we see no
> problem with ncurses-5.5 make-install in this regard.  But since
> ncurses-5.6 can't detect our glibtool as being a real GNU libtool
> for some reason, I'm quite stuck at trying to upgrade our
> /usr/local test libs with ncurses-5.6 or trying the later
> patches for ncurses-5.5.

I think the immediate problem is why the configure script's not
getting the libtool version.

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

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