bug-ncurses
[Top][All Lists]
Advanced

[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
        --with-system-type=darwin5
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
line.

> 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>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

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