bugGNU gettext - Bugs: bug #21980, can't open...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #21980: can't open /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libncurses.5.4.dylib referenced from libgettextsrc.dylib

Submitter:  Ryan Carsten Schmidt <ryandesign>
Submitted:  Tue 08 Jan 2008 01:24:10 PM UTC
   
 
Category:  Build Severity:  3 - Normal
Item Group:  None Status:  Fix Released
Privacy:  Public Assigned to:  haible
Open/Closed:  Closed

Jump to the original submission

Thu 17 Jan 2008 01:44:07 AM UTC, comment #7: 

Nothing can be said at this point about when 0.18 will be released.

You can track down the necessary patch, relative to 0.17, by
looking at the ChangeLog entries and the CVS. But it's more
comfortable to just take the snapshot that I made for you, and
use that. Please save a copy of the snapshot for your users: I
remove snapshots from my website at some time.

Bruno Haible <haible>
Group administrator
Thu 17 Jan 2008 01:03:16 AM UTC, comment #6: 

It works, thank you! Will 0.18 be released soon, or if not, is there a patch I can apply to 0.17 to get this switch?

Ryan Carsten Schmidt <ryandesign>
Sun 13 Jan 2008 05:18:28 PM UTC, comment #5: 

I have added a new configure option --disable-curses.

You find a tarball for testing at
  http://www.haible.de/bruno/gnu/gettext-0.18-pre1.tar.gz

Bruno Haible <haible>
Group administrator
Sun 13 Jan 2008 04:24:46 AM UTC, comment #4: 

I tried adding --without-libncurses-prefix --without-libtermcap-prefix --without-libxcurses-prefix --without-libcurses-prefix to a local copy of the MacPorts portfile for gettext. It still builds against the libncurses in ${prefix}. MacPorts automatically adds -L${prefix}/lib for all portfiles so maybe that's why. If the libncurses in ${prefix}/lib is not usable, it still finds the one in /usr/lib.

Building on an actual PowerPC 10.3.9 machine is exactly the task I'm trying to avoid needing to do anymore by rewriting my entire build system to cross-compile. It should be possible to cross-compile.

If there is not already an option to disable ncurses support even if it's found, then I would like to request that one be added. Thanks.

Ryan Carsten Schmidt <ryandesign>
Sat 12 Jan 2008 01:20:12 PM UTC, comment #3: 


> the DEPENDENCIES file only mentions ncurses in connection with the color features of msgcat.


Yes; this is correct.

> how would I instruct the gettext build process to forget about ncurses altogether


You can pass the options --without-libncurses-prefix --without-libtermcap-prefix --without-libxcurses-prefix --without-libcurses-prefix. Then the build will not search for
the curses library any more; but maybe it will still find the
one in /usr/lib or in the directory specified through the -L
option (without searching).

If everything else fails, I would attempt a native build on a
machine running MacOS X 10.3.9. This is known to work (I build
gettext on such a machine frequently).

But I think I should add to the new gettext version an option
--disable-curses that will refrain from linking to any curses
library even if it finds one. Have I understood you correctly?

Bruno Haible <haible>
Group administrator
Sat 12 Jan 2008 09:12:10 AM UTC, comment #2: 

Requiring DYLD_LIBRARY_PATH is not really suitable, and I don't know how to instruct the linker to look in the SDK instead of in /usr/lib. Anyway, if ncurses is required, I'll build it myself instead and use that. But the DEPENDENCIES file only mentions ncurses in connection with the color features of msgcat. That's not important to me in this context; all I care about here is that glib can find and use the gettext programs and libraries during compilation and I don't think it'll need color to do that. The DEPENDENCIES file says ncurses is "highly recommended" but doesn't say it's required. So how would I instruct the gettext build process to forget about ncurses altogether, even if it is installed?

Ryan Carsten Schmidt <ryandesign>
Wed 09 Jan 2008 02:02:20 AM UTC, comment #1: 

ncurses is highly recommended; see the DEPENDENCIES file.

I think it's your linker who finds and reports the library
from /usr/lib. To fix the problem, you can
a) either instruct the linker to look in
/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib
instead of /usr/lib,
b) or add the option "-L/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib"
to the LDFLAGS and the option --disable-rpath to the configure
invocation. Note that this will create binaries that depend on
DYLD_LIBRARY_PATH.

Bruno Haible <haible>
Group administrator
Tue 08 Jan 2008 01:24:10 PM UTC, original submission:  

I'm trying to compile a PowerPC Mac OS X 10.3.9-compatible version of gettext 0.17 on an Intel Mac running Mac OS X 10.4.11. I had some initial difficulty with this (see bug #21866) but you helped me get it working.

The build completes now, but as I look through the voluminous stderr output, I see this line several times:


/usr/bin/ld: warning can't open dynamic library: /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/libncurses.5.4.dylib referenced from: ./.libs/libgettextsrc.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)


And it's true: there is no libncurses.5.4.dylib in /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib. There is only the library libncurses.5.dylib (and two symlinks, libcurses.dylib and libncurses.dylib, which point to it). There is a libncurses.5.4.dylib in /usr/lib, but it's supposed to be using the one from the SDK directory.

I'm not sure what parts of gettext use ncurses so I'm not sure how to test whether this is in fact broken. Is ncurses absolutely required? Can I tell gettext not to use ncurses at all? Or if it is essential, should I be building my own copy of ncurses rather than using the system copy? I'm trying to make my build of graphviz as self-contained as possible.

For this build, I have set the following environment variables:


CC=/usr/bin/gcc-4.0 -isysroot /Developer/SDKs/MacOSX10.3.9.sdk
CXX=/usr/bin/g++-4.0 -isysroot /Developer/SDKs/MacOSX10.3.9.sdk
CFLAGS=-O2 -arch ppc
CXXFLAGS=-O2 -arch ppc
LDFLAGS=-arch ppc
CPATH=/usr/local/graphviz/include
LIBRARY_PATH=/usr/local/graphviz/lib
PATH=/usr/local/graphviz/bin:/bin:/sbin:/usr/bin:/usr/sbin
MACOSX_DEPLOYMENT_TARGET=10.3


And I am configuring this way:


./configure \
--prefix=/usr/local/graphviz \
--enable-shared \
--disable-static \
--with-included-gettext \
--with-included-glib \
--with-included-libcroco \
--with-included-libxml \
--without-emacs \
--disable-java


Ryan Carsten Schmidt <ryandesign>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by ryandesign (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-04 haible StatusFixed Fix Released
    2016-11-26 haible CategoryNone Build
    2008-01-13 haible StatusReady For Test Fixed
    2008-01-09 haible StatusNone Ready For Test
        Assigned toNone haible
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code