--disable-nls

[Gaetan Nadon]

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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110205/85810398/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110205/85810398/attachment.pgp>