PR43839 almost fixed

PR43839 almost fixed

[Jack Howarth]

   I believe I have a fix for PR43839 (where the jni.exp
script doesn't honor --with-iconv as set during the build).
The following patch *almost* works...

Index: testsuite/Makefile.in
===================================================================
--- testsuite/Makefile.in	(revision 158624)
+++ testsuite/Makefile.in	(working copy)
@@ -401,6 +401,7 @@
 	@echo 'set host_triplet $(host_triplet)' >>site.tmp
 	@echo 'set target_alias "$(target_alias)"' >>site.tmp
 	@echo 'set target_triplet $(target_triplet)' >>site.tmp
+	@echo 'set libiconv "$(LIBICONV)"' >>site.tmp
 	@echo '## All variables above are generated by configure. Do Not Edit ##' >>site.tmp
 	@test ! -f site.exp || \
 	  sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
Index: testsuite/libjava.jni/jni.exp
===================================================================
--- testsuite/libjava.jni/jni.exp	(revision 158624)
+++ testsuite/libjava.jni/jni.exp	(working copy)
@@ -251,6 +251,7 @@
 }
 
 proc gcj_jni_get_cxxflags_invocation {} {
+  global libiconv
   global LIBJAVA
   if [info exists LIBJAVA] {
       set libjava $LIBJAVA;
@@ -267,7 +268,7 @@
   # to just make the linker find libgcc using -L options.
   # Similar logic applies to libgcj.
   if { [istarget "*-*-darwin*"] } {
-    lappend cxxflags -shared-libgcc -lgcj -liconv
+    lappend cxxflags "-shared-libgcc -lgcj $libiconv"
   }
 
   if { [istarget "*-*-solaris*"] } {


However the compilation of PR16923.c now fails with...

Executing on host: /sw/src/fink.build/gcc46-4.5.999-20100421/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.5.999-20100421/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.5.999-20100421/gcc-4.6-20100421/libjava/testsuite/libjava.jni/invocation/PR16923.c   -bind_at_load -multiply_defined suppress -I. -I.. -I/sw/src/fink.build/gcc46-4.5.999-20100421/gcc-4.6-20100421/libjava/testsuite/libjava.jni -I/sw/src/fink.build/gcc46-4.5.999-20100421/gcc-4.6-20100421/libjava/testsuite/../include -I/sw/src/fink.build/gcc46-4.5.999-20100421/gcc-4.6-20100421/libjava/testsuite/../classpath/include -fdollars-in-identifiers -L/sw/src/fink.build/gcc46-4.5.999-20100421/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs -ljvm {-shared-libgcc -lgcj -L/sw/lib -liconv}  -lm   -o PR16923    (timeout = 300)
xgcc: unrecognized option '-shared-libgcc -lgcj -L/sw/lib -liconv'
output is:
xgcc: unrecognized option '-shared-libgcc -lgcj -L/sw/lib -liconv'

FAIL: PR16923.c compilation

Can anyone explain why the above syntax ends up adding wrappering
curly brackets around the evaluated $libiconv. This doesn't seem
to happen for $subdir, etc in the same jni.exp script.
           Jack

Re: PR43839 almost fixed

[Dave Korn]

On 22/04/2010 03:25, Jack Howarth wrote:

> @@ -267,7 +268,7 @@
>    # to just make the linker find libgcc using -L options.
>    # Similar logic applies to libgcj.
>    if { [istarget "*-*-darwin*"] } {
> -    lappend cxxflags -shared-libgcc -lgcj -liconv
> +    lappend cxxflags "-shared-libgcc -lgcj $libiconv"
>    }

> Can anyone explain why the above syntax ends up adding wrappering
> curly brackets around the evaluated $libiconv.

  Because that's what lappend does: it takes a list of *multiple* arguments,
and appends them as list elements to a variable.  By adding those gratuitous
quotes, you've turned the lappend command from multiple args into a single arg
with embedded spaces; you're thinking of shell scripting, but this is TCL.

  http://www.google.com/search?q=tcl+lappend

brings up various man pages.

    cheers,
      DaveK