GNOME Bugzilla – Bug 588267
Weird flag propagated from libiconv test
Last modified: 2009-07-10 20:28:10 UTC
configure.in as of 2.26.3 (and looks same in git trunk): AC_ARG_WITH([libiconv], AC_HELP_STRING([--with-libiconv=PATH], [Prefix where libiconv is installed])) if test -d $withval; then ICONV_CFLAGS="-I$withval/include" ICONV_LIBS="-L$withval/lib" fi I don't use any --with-libconv flag because my libiconv does not require any additional -L flags. That means $withval is blank. However, 'test -d' is true (weird--not even a runtime diagnostic or syntax error!). That means I get ICONV_LIBS="-L/lib", and that flag propagates into the makefiles. I don't have a /lib on my system, so I get dozens of: ld: warning -L: directory name (/lib) does not exist during the build. Putting $w in quotes makes it handled properly (it appears) as an an actual argument to test-d, even if the variable itself is blank: 'test -d ""' is false. Will patch (and also check e-d-s) shortly...
Created attachment 138212 [details] [review] Fix quoting of path to 'test -d'
Created attachment 138214 [details] [review] Fix quoting of path to 'test -d' (evolution-data-server-2.26.3) This whole --with-libiconv seems needless though...why can't rely on user just pass -I and -L flags via CPPFLAGS and LDFLAGS, same as for any other lib that might be in a non-default location?
A good catch, but we got it already under bug #586806 and bug #586813. (In reply to comment #2) > This whole --with-libiconv seems needless though...why can't rely on user just > pass -I and -L flags via CPPFLAGS and LDFLAGS, same as for any other lib that > might be in a non-default location? That's a fair point. If you wouldn't mind filing a separate bug about it I can look at it after Monday's release (don't want to risk breaking anything on the Friday prior). *** This bug has been marked as a duplicate of 586806 ***