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

Submitted by:  Ryan Schmidt <ryandesign>
Submitted on:  Tue 08 Jan 2008 01:24:10 PM UTC  
 
Category: BuildSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Bruno Haible <haible>
Open/Closed: Closed

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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 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>
Project AdministratorIn charge of this item.
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 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>
Project AdministratorIn charge of this item.
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 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>
Project AdministratorIn charge of this item.
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:

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:

And I am configuring this way:

Ryan Schmidt <ryandesign>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 26 Nov 2016 11:52:25 PM UTChaibleCategoryNone=>Build
    Sun 13 Jan 2008 05:18:28 PM UTChaibleStatusReady For Test=>Fixed
    Wed 09 Jan 2008 02:02:20 AM UTChaibleStatusNone=>Ready For Test
      Assigned toNone=>haible
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1