Re: when linking on Solaris 64bit shared object using cc, -m64 should be used

Dne 10.06.14 16:30, Bob Friesenhahn napsal(a):
> On Mon, 9 Jun 2014, Petr Sumbera wrote:
>
>> Hi,
>>
>> I'm often getting following error:
>>
>> /usr/apr/1.5/build/sparcv9/libtool --silent --mode=link cc -o
>> mod_dtrace.la
>> -rpath /usr/apache2/2.2/libexec/sparcv9 -module -avoid-version
>> mod_dtrace.lo
>> ld: fatal: file .libs/mod_dtrace.o: wrong ELF class: ELFCLASS64
>> apxs:Error: Command failed with rc=131072
>>
>> Attached patch fixes the issue.
>
> Normally such options should already be included in CFLAGS (or sometimes
> works better in CC).  All of the software needs to be compiled with the
> same -m64 option.

In my case it's included during compilation but not included during 
linking. When ld is used instead of cc everything works.

Also using all CFLAGS during linking seemed to me inappropriate since 
most of them wouldn't be relevant for linking.

And finally I was uncertain with "CC=cc -m64". It appeared to me as 
something what can cause some troubles and should be rather avoided.

> When compiling using the Sun compiler and targeting 64-bits, I configure
> using something like
>
>    ./configure 'CC=/opt/SUNWspro/bin/cc -m64' ...
>
> Libtool is not multilib capable under Solaris.  That is, it does not
> automatically install a library into an architecture-specific
> subdirectory or search there either.  You might notice that the system
> does support different directories (e.g. '/lib/32', '/lib/64',
> '/lib/amd64') and GCC is multilib capable, putting its own 64-bit
> libraries in an architecture-specific subdirectory.

Yes. We do following:

https://hg.java.net/hg/solaris-userland~gate/file/aaef0df2e4f3/components/apr-1_5/patches/libtool.m4.patch

The second part of the patch is to workaround the linking problem I'm 
trying to find right solution.

Thanks,

Petr