[Bug java/49441] New: @LDLIBICONV@ lost from installed libgcj.spec

[Bug java/49441] New: @LDLIBICONV@ lost from installed libgcj.spec

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441

           Summary: @LDLIBICONV@ lost from installed libgcj.spec
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


Both current gcc trunk and gcc-4_6-branch no longer properly set @LDLIBICONV@
in the installed libgcj.spec. The odd part is that the libgcj.spec generated in
the build directory shows @LDLIBICONV@ expanded...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj    -L/sw/lib -liconv    -lz
%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}  %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fnon-call-exceptions     -fkeep-inline-functions

whereas the installed copy is missing the "-L/sw/lib -liconv"...

#
# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
#
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj        -lz
%{!Zdynamiclib:%{!Zbundle:-allow_stack_execute}}  %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fnon-call-exceptions     -fkeep-inline-functions

I suspect this is caused by...

------------------------------------------------------------------------
r169822 | rwild | 2011-02-04 00:51:57 -0500 (Fri, 04 Feb 2011) | 12 lines

Fix PR java/21206: Unrecognized option '-Wl,-rpath' for jv-convert

libjava/:
        PR java/21206
        * configure.ac (LDLIBICONV): New substituted variable, with
        instances of '-Wl,' removed from LIBICONV.
        * configure: Regenerate.
        * libgcj.spec.in: Use @LDLIBICONV@ not @LIBICONV@.
        * Makefile.in: Regenerate.
        * gcj/Makefile.in: Likewise.
        * include/Makefile.in: Likewise.
        * testsuite/Makefile.in: Likewise.

[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-06-17 00:09:42 UTC ---
I don't believe r169822 is the cause but I see what is happening. During the
build two libgcj.spec files are generated. One in
x86_64-apple-darwin11.0.0/libjava, which properly substitutes LDLIBICONV, and a
second in x86_64-apple-darwin11.0.0/i386/libjava which produces an empty string
for LDLIBICONV. A quick examination of the Makefile's in each directory shows
why.

[MacPro:darwin_objdir/x86_64-apple-darwin11.0.0/libjava] root# grep LDLIBICONV
*
Makefile:LDLIBICONV =  -L/sw/lib -liconv 
config.log:LDLIBICONV=' -L/sw/lib -liconv '
config.status:S["LDLIBICONV"]=" -L/sw/lib -liconv "

[[MacPro:x86_64-apple-darwin11.0.0/i386/libjava] root# grep LDLIBICONV *
Makefile:LDLIBICONV =   
config.log:LDLIBICONV='  '
config.status:S["LDLIBICONV"]="  "

It appears that the multi lib build doesn't pass along the value for LDLIBICONV
into the multi lib and that the installed gcj.spec must be coming out of
x86_64-apple-darwin11.0.0/i386/libjava.

[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-06-17 00:16:55 UTC ---
This same behavior exists for LIBICONV in the multi lib of libstdc++-v3...


[MacPro:darwin_objdir/x86_64-apple-darwin11.0.0/libstdc++-v3] howarth% grep
LIBICONV *
Makefile:LIBICONV = -L/sw/lib -liconv
Makefile:LTLIBICONV = -L/sw/lib -liconv -R/sw/lib
config.log:LIBICONV='-L/sw/lib -liconv'
config.log:LTLIBICONV='-L/sw/lib -liconv -R/sw/lib'
config.status:S["LTLIBICONV"]="-L/sw/lib -liconv -R/sw/lib"
config.status:S["LIBICONV"]="-L/sw/lib -liconv"


[MacPro:x86_64-apple-darwin11.0.0/i386/libstdc++-v3] howarth% grep LIBICONV *
Makefile:LIBICONV = 
Makefile:LTLIBICONV = 
config.log:LIBICONV=''
config.log:LTLIBICONV=''
config.status:S["LTLIBICONV"]=""
config.status:S["LIBICONV"]=""

but that build doesn't seem to be trying to set anything with LIBICONV in the
multi lib that is installed like libgcj.spec.

[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-06-17 12:50:52 UTC ---
How is gcj supposed to properly find its linkage libraries on x86_64 linux when
using -m32? Since only a single copy of libgcj.spec is installed and used for
both the default -m64 and -m32, this seems impossible to handle both via that
mechanism (ie passing -L/usr/lib64 -liconv for -m64  and -L/usr/lib -liconv for
-m32). It seems much better to simply drop @LDLIBICONV@ entirely from
libgcj,spec.in and move @LDLIBICONV@ onto the linkage of libgcj itself (since
it seems to be the only place were the iconv symbols are generated or used).

[Bug java/49441] @LDLIBICONV@ lost from installed libgcj.spec

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49441

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-06-17 13:05:33 UTC ---
PR49314 reports also problems with iconv and java.