From: Lorenzo Pesce <lpesce@uchicago.edu>
To: Andrew Haley <aph@redhat.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Issue on X86_64?
Date: Fri, 28 Mar 2008 22:31:00 -0000 [thread overview]
Message-ID: <431E7BBD-FE41-4515-BB9D-A86F3E632931@uchicago.edu> (raw)
In-Reply-To: <47ED4D1F.10106@redhat.com>
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
next prev parent reply other threads:[~2008-03-28 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 21:06 Lorenzo Pesce
2008-03-26 10:03 ` Andrew Haley
2008-03-28 17:20 ` Lorenzo Pesce
2008-03-28 17:45 ` Andrew Haley
2008-03-28 17:57 ` Lorenzo Pesce
2008-03-28 18:07 ` Andrew Haley
2008-03-28 18:41 ` Lorenzo Pesce
2008-03-28 19:55 ` Andrew Haley
2008-03-28 22:31 ` Lorenzo Pesce [this message]
2008-03-28 22:51 ` David Daney
[not found] <20080328191557.BDJ30009@m4500-01.uchicago.edu>
2008-03-29 1:02 ` David Daney
2008-03-29 3:21 Lorenzo Pesce
2008-03-29 4:17 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=431E7BBD-FE41-4515-BB9D-A86F3E632931@uchicago.edu \
--to=lpesce@uchicago.edu \
--cc=aph@redhat.com \
--cc=gcc-help@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).