Hi Ben, Le 5 oct. 2011 à 18:40, Ben Pfaff a écrit : > Akim Demaille <demaille@xxxxxxxxxx> writes: > >> The JVM is quite happy with that. Unless you make the name >> "invalid" by setting LC_ALL to C for instance, which Autoconf >> does. > > Glib supports a G_FILENAME_ENCODING environment variable that > directly controls the encoding used for file names. Does the JVM > have any equivalent? Thanks for the suggestion. I have tried to find something on the Internet, but I saw nothing conclusive. Some people seem to believe -Dfile.encoding=UTF-8 might help (but actually it's about the encoding for file I/O), but others point out that sun.jnu.encoding should do it (http://happygiraffe.net/blog/2009/09/24/java-platform-encoding/). Unfortunately it does not work here, and some are angry at the JVM (http://bugs.sun.com/bugdatabase/view%5Fbug.do?bug%5Fid=4733494). They advice to define LC_ALL properly (http://stackoverflow.com/questions/5663709/how-to-fix-java-when-if-refused-to-open-a-file-with-special-charater-in-filename). Apart from moving away from this directory with non-ASCII characters, the only way out I see currently is really to restore the locales when invoking the JVM. But that requires getting the user's locale, which is not something that Autoconf 2.68 allows to do: $ grep LC_ configure LC_ALL=C export LC_ALL LC_ALL=C export LC_ALL $ configure should probably save the previous locale values before overriding them all, that might be help on occasions, such as this one. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
