Bug 49441 - @LDLIBICONV@ lost from installed libgcj.spec
Summary: @LDLIBICONV@ lost from installed libgcj.spec
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-16 14:45 UTC by Jack Howarth
Modified: 2011-06-17 13:05 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2011-06-16 14:45:08 UTC
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.
Comment 1 Jack Howarth 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.
Comment 2 Jack Howarth 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.
Comment 3 Jack Howarth 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).
Comment 4 Dominique d'Humieres 2011-06-17 13:05:33 UTC
PR49314 reports also problems with iconv and java.