Issue on X86_64?

Issue on X86_64?

[Lorenzo Pesce]

Dear all,
I am preparing some free software that needs to work on different  
platforms (OS X, windows, Linux  x  32,64).
One problem I have is that this system is based upon a fortran core,  
a set of routines that do statistical calculations, which is used  
differently by either fortran, c or java drivers.

I package the procedures (.o) in three formats: a libroc.a and  
libroc.so and a libroc.so (as a jni lib).
I usually link the pieces of libgfortran.a (ar -x ...) so that users  
do not need to have libgfortran on their system. I then include those  
pieces when I build all the libraries.

The three formats build and work fine under gcc-4.1.1 on OS X 10.4  
(G4 or Xeon) and Linux Intel 32.

However, when I get to X86 (whether Intel or AMD) it does not work  
anymore. I can compile the files, and build the static library  
libroc.a. It works fine and I can move it from AMD to intel (not the  
other way around, but I assume it is a problem with my installation).  
However, when I try to build a dynamically linked library, gcc  
complains that
"Relocation R_X86_64_32 against 'a local symbol' can not be used when  
making a share object; recompile with -fPIC"
then it tells me it can't read symbols .o because it is a bad value.

If I link the libgfortran.so or load the libgfortran.so it works  for  
R. However, the result works either on AMD or Intel.

However, it does not work for the java jnilib because it thinks that  
it is the wrong ELF class: ELFCLASS64 (which it is).

I would like to use the .o's of libgfortran directly because that  
would allow me to have a single library for both Intel and AMD and  
also to make my development tree somewhat simpler. Not to mention  
that I would like to understand what is happening.

What am I doing wrong?

Lorenzo

Re: Issue on X86_64?

[Andrew Haley]

Lorenzo Pesce wrote:
> Dear all,
> I am preparing some free software that needs to work on different
> platforms (OS X, windows, Linux  x  32,64).
> One problem I have is that this system is based upon a fortran core, a
> set of routines that do statistical calculations, which is used
> differently by either fortran, c or java drivers.
> 
> I package the procedures (.o) in three formats: a libroc.a and libroc.so
> and a libroc.so (as a jni lib).
> I usually link the pieces of libgfortran.a (ar -x ...) so that users do
> not need to have libgfortran on their system. I then include those
> pieces when I build all the libraries.
> 
> The three formats build and work fine under gcc-4.1.1 on OS X 10.4 (G4
> or Xeon) and Linux Intel 32.
> 
> However, when I get to X86 (whether Intel or AMD) it does not work
> anymore. I can compile the files, and build the static library libroc.a.
> It works fine and I can move it from AMD to intel (not the other way
> around, but I assume it is a problem with my installation). However,
> when I try to build a dynamically linked library, gcc complains that
> "Relocation R_X86_64_32 against 'a local symbol' can not be used when
> making a share object; recompile with -fPIC"
> then it tells me it can't read symbols .o because it is a bad value.

You need to compile everything that goes into a dynamically linked library
with -fPIC.

> If I link the libgfortran.so or load the libgfortran.so it works  for R.
> However, the result works either on AMD or Intel.
> 
> However, it does not work for the java jnilib because it thinks that it
> is the wrong ELF class: ELFCLASS64 (which it is).

I'm guessing you have a 32-bit JVM, so you'll need to compile the jni
library with -m32.

> I would like to use the .o's of libgfortran directly because that would
> allow me to have a single library for both Intel and AMD and also to
> make my development tree somewhat simpler. Not to mention that I would
> like to understand what is happening.
> 
> What am I doing wrong?

I don't think you can have a single library with both 32-bit and 64-bit
binaries.

Andrew.

Re: Issue on X86_64?

[Lorenzo Pesce]

Thanks a lot for your kinds replied Andrew,

>> However, when I get to X86 (whether Intel or AMD) it does not work
>> anymore. I can compile the files, and build the static library  
>> libroc.a.
>> It works fine and I can move it from AMD to intel (not the other way
>> around, but I assume it is a problem with my installation). However,
>> when I try to build a dynamically linked library, gcc complains that
>> "Relocation R_X86_64_32 against 'a local symbol' can not be used
>> when making a share object; recompile with -fPIC"
>> then it tells me it can't read symbols .o because it is a bad value.
>
> You need to compile everything that goes into a dynamically linked
> library with -fPIC.

I have to admit my ignorance on compilers building, but once i
download unpack and so on the gcc compiler package, I can't
figure out in which of the hundreds of lines of the  various makefiles
or configuration files I should put the -fPIC flag.
>>

Forgive my naive question,

  Lorenzo

Re: Issue on X86_64?

[Andrew Haley]

Lorenzo Pesce wrote:
> Thanks a lot for your kinds replied Andrew,
> 
>>> However, when I get to X86 (whether Intel or AMD) it does not work
>>> anymore. I can compile the files, and build the static library libroc.a.
>>> It works fine and I can move it from AMD to intel (not the other way
>>> around, but I assume it is a problem with my installation). However,
>>> when I try to build a dynamically linked library, gcc complains that
>>> "Relocation R_X86_64_32 against 'a local symbol' can not be used
>>> when making a share object; recompile with -fPIC"
>>> then it tells me it can't read symbols .o because it is a bad value.
>>
>> You need to compile everything that goes into a dynamically linked
>> library with -fPIC.
> 
> I have to admit my ignorance on compilers building, but once i
> download unpack and so on the gcc compiler package, I can't
> figure out in which of the hundreds of lines of the  various makefiles
> or configuration files I should put the -fPIC flag.

Don't mess with gcc's makefiles.
gcc already builds all of its files correctly.

When you use gcc to build *your* libraries, *you* must compile everything
with -fPIC.

Andrew.

Re: Issue on X86_64?

[Lorenzo Pesce]

On Mar 28, 2008, at 12:45 PM, Andrew Haley wrote:

> Lorenzo Pesce wrote:
>> Thanks a lot for your kinds replied Andrew,
>>
>>>> However, when I get to X86 (whether Intel or AMD) it does not work
>>>> anymore. I can compile the files, and build the static library  
>>>> libroc.a.
>>>> It works fine and I can move it from AMD to intel (not the other  
>>>> way
>>>> around, but I assume it is a problem with my installation).  
>>>> However,
>>>> when I try to build a dynamically linked library, gcc complains  
>>>> that
>>>> "Relocation R_X86_64_32 against 'a local symbol' can not be used
>>>> when making a share object; recompile with -fPIC"
>>>> then it tells me it can't read symbols .o because it is a bad  
>>>> value.
>>>
>>> You need to compile everything that goes into a dynamically linked
>>> library with -fPIC.
>>
>> I have to admit my ignorance on compilers building, but once i
>> download unpack and so on the gcc compiler package, I can't
>> figure out in which of the hundreds of lines of the  various  
>> makefiles
>> or configuration files I should put the -fPIC flag.
>
> Don't mess with gcc's makefiles.
> gcc already builds all of its files correctly.
>
> When you use gcc to build *your* libraries, *you* must compile  
> everything
> with -fPIC.

I already do that. The problem is with libgfortran.* not with my  
libraries!

Java seems to need the object files from libgfortran for the JNI  
libraries to work properly so I need
libgfortran to be compiled with -fPIC to link them into the jni  
library. My libraries have always been built with -fPIC,
it is libgfortran that is breaking on the x86_64, not my libraries.

Does it make sense?

Lorenzo

Re: Issue on X86_64?

[Andrew Haley]

Lorenzo Pesce wrote:
> 
> On Mar 28, 2008, at 12:45 PM, Andrew Haley wrote:
> 
>> Lorenzo Pesce wrote:
>>> Thanks a lot for your kinds replied Andrew,
>>>
>>>>> However, when I get to X86 (whether Intel or AMD) it does not work
>>>>> anymore. I can compile the files, and build the static library
>>>>> libroc.a.
>>>>> It works fine and I can move it from AMD to intel (not the other way
>>>>> around, but I assume it is a problem with my installation). However,
>>>>> when I try to build a dynamically linked library, gcc complains that
>>>>> "Relocation R_X86_64_32 against 'a local symbol' can not be used
>>>>> when making a share object; recompile with -fPIC"
>>>>> then it tells me it can't read symbols .o because it is a bad value.
>>>>
>>>> You need to compile everything that goes into a dynamically linked
>>>> library with -fPIC.
>>>
>>> I have to admit my ignorance on compilers building, but once i
>>> download unpack and so on the gcc compiler package, I can't
>>> figure out in which of the hundreds of lines of the  various makefiles
>>> or configuration files I should put the -fPIC flag.
>>
>> Don't mess with gcc's makefiles.
>> gcc already builds all of its files correctly.
>>
>> When you use gcc to build *your* libraries, *you* must compile everything
>> with -fPIC.
> 
> I already do that. The problem is with libgfortran.* not with my libraries!

Now you tell me.  Have a look at the gcc build log to see if it really
did compile some of the libgfortran sources without -fPIC.

> Java seems to need the object files from libgfortran for the JNI
> libraries to work properly

No it doesn't.

> so I need
> libgfortran to be compiled with -fPIC to link them into the jni library.
> My libraries have always been built with -fPIC,
> it is libgfortran that is breaking on the x86_64, not my libraries.
> 
> Does it make sense?

No.  Java does not depend on libgfortran, or at least it certainly doesn't
on any system I have ever seem.

If you find somewhere it does, please make a test case that we can try.

Andrew.

Re: Issue on X86_64?

[Lorenzo Pesce]

>>> When you use gcc to build *your* libraries, *you* must compile
>>> with -fPIC.
>>
>> I already do that. The problem is with libgfortran.* not with my  
>> libraries!
>
> Now you tell me.  Have a look at the gcc build log to see if it really
> did compile some of the libgfortran sources without -fPIC.

Forgive me again, which is the file I should look for?
I am looking in  gcc-4.1.1/objdir and this is all I can find:

x86_64-unknown-linux-gnu/libgfortran/libtool:140:pic_flag=" -fPIC -DPIC"
x86_64-unknown-linux-gnu/libgfortran/config.cache: 
259:ac_cv_prog_cc_pic=${ac_cv_prog_cc_pic=' -fPIC -DPIC'}
x86_64-unknown-linux-gnu/libgfortran/config.log:175:ltconfig: 
687:checking that /home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc PIC  
flag -fPIC -DPIC works.
x86_64-unknown-linux-gnu/libgfortran/config.log:176:ltconfig:697: / 
home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc -B/home/lpesce/GCC/ 
gcc-4.1.1/objdir/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/ 
usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64- 
unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux- 
gnu/sys-include -c -std=gnu99 -O2 -g -O2  -fPIC -DPIC -DPIC   
conftest.c 1>&5
x86_64-unknown-linux-gnu/libgfortran/config.log: 
5096:ac_cv_prog_cc_pic=' -fPIC -DPIC'
x86_64-unknown-linux-gnu/32/libgfortran/libtool:140:pic_flag=" -fPIC - 
DPIC"
x86_64-unknown-linux-gnu/32/libgfortran/config.cache: 
259:ac_cv_prog_cc_pic=${ac_cv_prog_cc_pic=' -fPIC -DPIC'}
x86_64-unknown-linux-gnu/32/libgfortran/config.log:175:ltconfig: 
687:checking that /home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc PIC  
flag -fPIC -DPIC works.
x86_64-unknown-linux-gnu/32/libgfortran/config.log:176:ltconfig:697: / 
home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc -B/home/lpesce/GCC/ 
gcc-4.1.1/objdir/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/ 
usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64- 
unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux- 
gnu/sys-include  -m32 -c -std=gnu99  std=gnu99 -O2 -g -O2  -Wunknown- 
pragmas -fPIC -DPIC -DPIC  conftest.c 1>&5
x86_64-unknown-linux-gnu/32/libgfortran/config.log: 
5146:ac_cv_prog_cc_pic=' -fPIC -DPIC'

>> Java seems to need the object files from libgfortran for the JNI
>> libraries to work properly
>
> No it doesn't.

Sorry, I did not report all the steps. I am constructing some jni  
libraries from
some fortran libraries. I seem to be able to use the fortran  
libraries as jni
if and only if the objects from libgfortran are included into the  
dynamically
linked jni library.
>>

I hope that it makes more sense now.

Lorenzo

Re: Issue on X86_64?

[Andrew Haley]

Lorenzo Pesce wrote:
>>>> When you use gcc to build *your* libraries, *you* must compile
>>>> with -fPIC.
>>>
>>> I already do that. The problem is with libgfortran.* not with my
>>> libraries!
>>
>> Now you tell me.  Have a look at the gcc build log to see if it really
>> did compile some of the libgfortran sources without -fPIC.
> 
> Forgive me again, which is the file I should look for?
> I am looking in  gcc-4.1.1/objdir and this is all I can find:

Unless you looged the build, you won't have it all, but this looks as though
the PIC flag was correctly set:

> 
> x86_64-unknown-linux-gnu/libgfortran/libtool:140:pic_flag=" -fPIC -DPIC"
> x86_64-unknown-linux-gnu/libgfortran/config.cache:259:ac_cv_prog_cc_pic=${ac_cv_prog_cc_pic='
> -fPIC -DPIC'}
> x86_64-unknown-linux-gnu/libgfortran/config.log:175:ltconfig:687:checking
> that /home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc PIC flag -fPIC -DPIC
> works.
> x86_64-unknown-linux-gnu/libgfortran/config.log:176:ltconfig:697:
> /home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc
> -B/home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/
> -B/usr/local/x86_64-unknown-linux-gnu/bin/
> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
> /usr/local/x86_64-unknown-linux-gnu/include -isystem
> /usr/local/x86_64-unknown-linux-gnu/sys-include -c -std=gnu99 -O2 -g
> -O2  -fPIC -DPIC -DPIC  conftest.c 1>&5
> x86_64-unknown-linux-gnu/libgfortran/config.log:5096:ac_cv_prog_cc_pic='
> -fPIC -DPIC'
> x86_64-unknown-linux-gnu/32/libgfortran/libtool:140:pic_flag=" -fPIC -DPIC"
> x86_64-unknown-linux-gnu/32/libgfortran/config.cache:259:ac_cv_prog_cc_pic=${ac_cv_prog_cc_pic='
> -fPIC -DPIC'}
> x86_64-unknown-linux-gnu/32/libgfortran/config.log:175:ltconfig:687:checking
> that /home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc PIC flag -fPIC -DPIC
> works.
> x86_64-unknown-linux-gnu/32/libgfortran/config.log:176:ltconfig:697:
> /home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/xgcc
> -B/home/lpesce/GCC/gcc-4.1.1/objdir/./gcc/
> -B/usr/local/x86_64-unknown-linux-gnu/bin/
> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
> /usr/local/x86_64-unknown-linux-gnu/include -isystem
> /usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 -c -std=gnu99 
> std=gnu99 -O2 -g -O2  -Wunknown-pragmas -fPIC -DPIC -DPIC  conftest.c 1>&5
> x86_64-unknown-linux-gnu/32/libgfortran/config.log:5146:ac_cv_prog_cc_pic='
> -fPIC -DPIC'
> 
>>> Java seems to need the object files from libgfortran for the JNI
>>> libraries to work properly
>>
>> No it doesn't.
> 
> Sorry, I did not report all the steps. I am constructing some jni
> libraries from
> some fortran libraries. I seem to be able to use the fortran libraries
> as jni
> if and only if the objects from libgfortran are included into the
> dynamically
> linked jni library.

Well, that is very odd.  As long as you link against all the 
libraries, you should not need any static libraries.

We need specifics.  What you are describing is a bug; we need to know
exactly what happens when you try to link dynamically with FORTRAN and Java.

Anything else is doomed to fail.

Andrew.

Re: Issue on X86_64?

[Lorenzo Pesce]

Andrew,
Let's go over the facts.
*) All my files are compiled with -fPIC and always were.
*) When I compile I build the basic library, called libroc.a, so it  
is static.
  I mean it to be static so I can give it to people and they don't  
need gfortran.
The library works fine, whether I add the .o from libgfortran.a (ar - 
x librgfortran.a),
or whether I compile invoking libgfortran.a from g++.
*) The library.a can be linked and works from any Linux X86_64 that I  
could find.
*) The jni library, the dynamically linked library and all the rest  
compiles, builds and runs fine on OS X, Windows and Linux 32.

However, when I try to build a dynamically linked library to be  
loaded by java, including the .o files from libgfortran.a

% g++ -shared -fPIC -o libroc.so -I/usr/java/jdk/include -I/usr/java/ 
jdk/include/linux rocJniFortran_LINUX.c libroc.a
/usr/bin/ld: libroc.a(close.o): relocation R_X86_64_32 against `a  
local symbol' can not be used when making a shared object; recompile  
with -fPIC
libroc.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

Note that all the pieces of java are in place and EVERY piece of my  
library is built using -fPIC.

If I do not include the .o files from libgfortran:

g++ TestGetAzValue_LINUX.cpp libroc.a /usr/lib/gcc/x86_64-redhat- 
linux/4.1.1/libgfortran.a

I did not follow this path because I expect that when java will load  
the library on a different machine it will be
looking for a suitable libgfortran.so and die if it isn't there.

The java does this to me.

java: symbol lookup error: /Projects/ROC/users/lpesce/ROC/java/ 
libroc.so: undefined symbol: _gfortran_internal_malloc64

Which perhaps means that it can't find the library or ...

Remember that this project, as is, works perfectly fine on nearly  
every other system.

It does not work on gcc-4.2 and above because of what seems to be a  
pesky bug in that release (for Linux only, I build on on gcc-4.3 on  
OS X).

I might be wrong about all of it, of course.

Lorenzo

Re: Issue on X86_64?

[David Daney]

Lorenzo Pesce wrote:

> However, when I try to build a dynamically linked library to be loaded 
> by java, including the .o files from libgfortran.a
> 

This seems like a bad thing to do.  libgfortran.a does not contain PIC 
code, so its members cannot be put in a shared library.  You should link 
against libgfortran.so

David Daney

Re: Issue on X86_64?

[Ian Lance Taylor]

Lorenzo Pesce <lpesce@uchicago.edu> writes:

> It seems like they are in "objdir"/x86_64-xxx-gnu/libgfortran.
> Unfortunately, the .o do not seem to be build with as PIC and
> the .lo do not seem to be digestible by g++, gcc. So I don't
> know how to coax them into a dyn lib.

You'll find the PIC versions of the libgfortran object files in the
TARGET/libgfortran/.libs directory.

There are absolutely no guarantees that this will be true in any
future release of gcc.

Ian

Re: Issue on X86_64?

[Lorenzo Pesce]

Thanks for your reply David,

>> Much easier for me would be to have access to the objects of
>> libgortran.a compiled as PIC. I don't care for many parts of
>> the .so because the code runs only as a library.
>> 
>> 
>> Does it make sense?
>
> I understand what you are saying, but I don't necessarily 
> agree that it is the 'right thing to do'.

It is the best solution I could find. I would love to hear 
a better idea because there is something illogical about this
"fix", but still, it seems to be the smallest evil.


>The object files you need exist somewhere in the gcc build
> tree (but not in any archive), you need to figure out how
> to get them out.

It seems like they are in "objdir"/x86_64-xxx-gnu/libgfortran.
Unfortunately, the .o do not seem to be build with as PIC and
the .lo do not seem to be digestible by g++, gcc. So I don't
know how to coax them into a dyn lib.

This why I thought to rebuild the gfortran's .o with -fPIC, 
but got baffled by Makefiles and config files. I could not 
find any mention of it anywhere. 
 
Any ideas?

Thanks again, and sorry for taking up so much bandwidth, I 
hope it is of some interest to other people as well.

Lorenzo

Re: Issue on X86_64?

[David Daney]

Lorenzo Pesce wrote:
> David,
> 
>>> However, when I try to build a dynamically linked library
> to be loaded 
>>> by java, including the .o files from libgfortran.a
>>>
>> This seems like a bad thing to do.  libgfortran.a does not
> contain PIC code, so its members cannot be put in a shared
> library.  You should link against libgfortran.so
> 
> This would seem the right solution on the surface, however,
> if I link against the .so, i have three problems:
> 1) When I release the code to the masses, they need one
> additional library. My issues is not with running my code but
> rather with my users (I have thousands of users and they are
> not very good with their computers).
> 2) Java needs to find where the library is and it does not
> seem to work.
> 3) The .so, because of libstc's and so on, port fairly poorly,
> so even if I wanted to include them in a release, it would
> still be a pain.
> 
> Much easier for me would be to have access to the objects of
> libgortran.a compiled as PIC. I don't care for many parts of
> the .so because the code runs only as a library.
> 
> 
> Does it make sense?

I understand what you are saying, but I don't necessarily agree that it 
is the 'right thing to do'.

The object files you need exist somewhere in the gcc build tree (but not 
in any archive), you need to figure out how to get them out.

David Daney