Hi,
(if you have received this twice, sorry my fault)
I have some additional information on my problem
(found on
http://www.redhat.com/docs//manuals/enterprise/RHEL-4-Manual/gnu-assembler/cris-syntax.html,
thanks to B.Kolb)
When generating position-independent code (SVR4 PIC) for use in
cris-axis-linux-gnu shared libraries, symbol suffixes are used to
specify what kind of run-time symbol lookup will be used, expressed in
the object as different /relocation types/. Usually, all absolute
symbol values must be located in a table, the /global offset table/,
leaving the code position-independent; independent of values of global
symbols and independent of the address of the code. The suffix
modifies the value of the symbol, into for example an index into the
global offset table where the real symbol value is entered, or a
PC-relative value, or a value relative to the start of the global
offset table. [...]
GOT
Attaching this suffix to a symbol in an instruction causes the
symbol to be entered into the global offset table. The value is a
32-bit index for that symbol into the global offset table. The
name of the corresponding relocation is R_CRIS_32_GOT. [...]
[...]
PLT
This suffix is used for function symbols. It causes a /procedure
linkage table/, an array of code stubs, to be created at the time
the shared object is created or linked against, together with a
global offset table entry. The value is a pc-relative offset to
the corresponding stub code in the procedure linkage table. This
arrangement causes the run-time symbol resolver to be called to
look up and set the value of the symbol the first time the
function is called (at latest; depending environment variables).
It is only safe to leave the symbol unresolved this way if all
references are function calls. The name of the relocation is
R_CRIS_32_PLT_PCREL. [...]
[...]
GOTPLT
Similar to PLT, but the value of the symbol is a 32-bit index into
the global offset table. This is somewhat of a mix between the
effect of the GOT and the PLT suffix; the difference to GOT is
that there will be a procedure linkage table entry created, and
that the symbol is assumed to be a function entry and will be
resolved by the run-time resolver as with PLT. The relocation is
R_CRIS_32_GOTPLT.[...]
... so does this mean shared libraries are used although
-Wl,-Bstatic -static-libgcc
is used?
Again any help is welcome.
Peter
Dr. Peter Zumbruch wrote:
Hello everybody,
I am trying to cross compile and link an application based on stream
device and asyn
with patched base 3.14.10 on a linux-x86_64 system with the
linux-cris_v10 as target.
Stream and Asyn have been compiled for the host and target architectures.
When building the application the final linking for the target failes
with this command
(which I just split up for better reading, and paths shortened <..>):
cris-g++ -o streamHadcon
-Wl,-Bstatic -static-libgcc
-Wl,--strip-all
-L<IOC_TOP>/lib/linux-cris_v10
-L<EPICS_HOME>/base/lib/linux-cris_v10
-L<EPICS_HOME>/modules/soft/StreamDevice/lib/linux-cris_v10
-L<EPICS_HOME>/modules/soft/asyn/asyn-4.11a/lib/linux-cris_v10
-Wl,-rpath,<IOC_TOP>/lib/linux-cris_v10
-Wl,-rpath,<EPICS_HOME>/base/lib/linux-cris_v10
-Wl,-rpath,<EPICS_HOME>/modules/soft/StreamDevice/lib/linux-cris_v10
-Wl,-rpath,<EPICS_HOME>/modules/soft/asyn/asyn-4.11a/lib/linux-cris_v10
-L<AXIS_TOP>/target/cris-axis-linux-gnu/lib
-L<AXIS_TOP>/target/cris-axis-linux-gnu/usr/lib
streamHadcon_registerRecordDeviceDriver.o streamHadconMain.o
-lstreamHadconSupport
-lrecIoc
-lsoftDevIoc
-lmiscIoc
-lrsrvIoc
-ldbtoolsIoc
-lasIoc
-ldbIoc
-lregistryIoc
-ldbStaticIoc
-lca
-lCom
-lstream
-lasyn
-lpthread
-lm
-lrt
resulting in this output:
<EPICS_ASYN>/lib/linux-cris_v10/libasyn.a(devAsynInt32.o): In
function `getIoIntInfo':
epicsTypeClass/../../asyn/devEpics/devAsynInt32.c:288: undefined
reference to `epicsRingBytesCreate'
[..]/cris-axis-linux-gnu/bin/ld:
<EPICS_ASYN>/lib/linux-cris_v10/libasyn.a(devAsynInt32.o): No PLT for
relocation R_CRIS_32_GOTPLT against symbol `epicsRingBytesCreate'
from .text section
[..]/cris-axis-linux-gnu/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
Notes:
- But 'epicsRingBytesCreate' is defined in libasyn.a(devAsynInt32.o),
(cris-)nm gives consistent results
- Unfortunately in addition I do not fully get the meaning of the error
- It does compile for linux-x86_64
- base itself needed an independent patch for _64 architecture in base
CONFIG.linux-x86_64.linux-cris(_v10/32) copy linux-x86 (to be
committed soon)
Since I did the port of EPICS to cris,
has anybody else seen such a response or something similar when cross
building an application?
Any help appreciated,
Thanks, Peter
--
Dr. rer. nat. Peter W. Zumbruch
EE - department / Controls group / GSI
E-Mail: P.Zumbruch_at_gsi.de
Tel: +49-(6159)-71-1435 / Fax: +49-(6159)-71-2986
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1 / D-64291 Darmstadt / www.gsi.de
Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Darmstadt
Handelsregister: Amtsgericht Darmstadt, HRB 1528
Geschäftsführung: Professor Dr. Dr. h.c. Horst Stöcker,
Christiane Neumann, Dr. Hartmut Eickhoff
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph,
Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt
- References:
- No PLT for relocation Dr. Peter Zumbruch
- Navigate by Date:
- Prev:
Re: No PLT for relocation Peter Zumbruch
- Next:
compiling synApps std Pierrick Hanlet
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: No PLT for relocation Peter Zumbruch
- Next:
compiling synApps std Pierrick Hanlet
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|