<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Sat, 2011-02-05 at 11:51 -0800, Jeremy Huddleston wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Feb 5, 2011, at 06:03, Gaetan Nadon wrote: > On Fri, 2011-02-04 at 13:56 -0800, Jeremy Huddleston wrote: > >>>> It looks like libXpm ... does not honor --disable-nls. >> > > and it does not need to. Actually, it should, in order to disable undersired support or pull in undesired dependencies. </PRE> </BLOCKQUOTE> Agreed. The code in configure.ac appeared to not pull-in undesired support/dependencies. <BLOCKQUOTE TYPE=CITE> <PRE> > The libXpm package has a minimalist custom configuration to locate the > gettext function in the intl library provided by the intltool. The sxpm > and cxpm apps have isolated translatable strings into separate files. > These messages strings have not been translated and are not installed in > share/locale. I have libintl on my system from MacPorts, it is not shipped with OS X.  I've been shipping XQuartz builds that don't use libintl (because it's not on the system), and I've been using --disable-nls to enforce that. With the latest build, however, I was experimenting with different toolchains, and the MacPorts prefix was searched for libraries, and it picked up -lintl even though I didn't want it to.  If I had shipped the resulting binaries, users would've had unresolved dependencies (on libintl). </PRE> </BLOCKQUOTE> Thanks for the info. So far I had no idea what the problem was :-) The code has a way to disable nsl by using <TT>--without-localedir. </TT>It won't prevent the search for intl however. This, by itself should not be harmful, but if intl is found, it is pre-pended to $LIB which may cause over linking. You will need to verify that option. <BLOCKQUOTE TYPE=CITE> <PRE> > The package does not use AM_GNU_GETTEXT and therefore the disable-nls > option does not exist. The nls support cannot be more disabled than it > is now. Why not? </PRE> </BLOCKQUOTE> I have tried it and it pulls in a lot of stuff, writes directories and so on. But that's another option. I doubt it will not pull in intl if it finds one. <BLOCKQUOTE TYPE=CITE> <PRE> > This option comes from the nls.m4 macro installed by > AM_GNU_GETTEXT in the package m4 directory for those who use the macro. > > The correct fix for this situation is to remove this option from the > command line when configuring libXpm. I would not recommend spending > effort in adding nls support so it can be disabled by this option. Then how do you suggest I handle this?  My current workaround is to move the libraries out of the way during configure time. </PRE> </BLOCKQUOTE> I see a couple more options. Move AC_SEARCH_LIBS under an if statement along with the --without-localedir option. This will ensure there is no traces left. Wrap the whole gettext configure code under a "darwin" case statement. So you have 4 options now. Out of curiosity, given that --disable-nls isn't in xorg at all, how was this option recognized before? It is an interesting scenario. Often the configuration uses the presence of a library function as a trigger to turn a feature on, which may not always be desirable. <BLOCKQUOTE TYPE=CITE> <PRE> --Jeremy </PRE> </BLOCKQUOTE> </BODY> </HTML>