On Sat, 2011-02-05 at 11:51 -0800, Jeremy Huddleston wrote: > 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.
Agreed. The code in configure.ac appeared to not pull-in undesired support/dependencies. > > > 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). > Thanks for the info. So far I had no idea what the problem was :-) The code has a way to disable nsl by using --without-localedir. 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. > > > 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? 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. > > > 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. 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. > > --Jeremy > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
