Hi Bill,
I think I have all the issues addressed based on your suggestions.
I ran into another similar (to issue 2) problem today on Pleiades at
NASA where the binutils as assembler was getting invoked and cause
xerces-c to file to configure. So, I've changed our binutils build
to not install the bin tools (ld, ar, as, etc.).
Also, I'm not seeing any checks that our OSS build is doing that
would let libdwarf.a be recognised as an acceptable dwarf
installation. We seem to be only checking for libdwarf.so and will
build a shared version of libdwarf if we don't find libdwarf.so. I
thought we were checking for libdwarf.a and allowing that to satisfy
the requirement. So, I may need more information from Engelbert on
the libdwarf installed on his platform to see why the issue 3 is
happening.
For BG/Q, I put in a check to see if we are on a BG machine and then
switching the version of dyninst to 8.1.2. This bloats the source
directory a bit, but should be ok for a while.
I have put out a new tarball ( rc2-openspeedshop-release-2.1-u3.tar.gz ) on
sourceforge for Engelbert and others to try.
Thanks for your help.
Jim G
On 04/14/2014 09:09 AM, Bill Williams
wrote:
Jim--
Trimming things down to issues that remain open w.r.t. 8.2:
>> 2) Does /opt/krellroot_v2.1u3/bin/ld work for linking
object files
built with gcc? Is this the linker you
intend to use? You're mixing
toolchains here (that linker with /usr/bin/gcc) and I have no
idea
whether that's deliberate or not, and no idea whether the
toolchains
in question are compatible.
I don't know exactly what to do with this. If I need to install
binutils, then it is in the krellroot which is used to reference
other
needed components that might not be installed. ld gets
installed into
the krellroot when binutils is built. You are correct, though.
Manually moving ld to ld-back and rerunning the dyninst build
allows it
to succeed.
I am presuming that you need various binutils components as direct
O|SS dependencies and not just as Dyninst depedencies here. IIRC
it's possible to coerce binutils into building each of its
components separately, though "coerce" is absolutely the right
verb--unless my memory is slipping, we do this for libiberty. I
can see three general approaches here:
1) Only build the binutils components you need
2) Prune the binutils install to the set of components you need
3) Add the krell auxiliary directories at the end, rather than the
beginning, of the assorted path variables (assuming that the goal
is to augment what's available and not to replace something that's
already present).
3) libdwarf must be built PIC or shared (we generally go for
shared)
in order to link--we do not support deferred linking of static
libraries into a dyninst-based executable. Grab source and
build with
--enable-shared, or let Dyninst's CMake do it for you
automatically.
We do build libdwarf shared when it is determined we need to
build it.
So, I check for libdwarf.so and then for libdwarf.a, but do not
check
for whether or not libdwarf is compiled with -fPIC. I found a
discussion on the internet that said you can check for that by
doing
something like this:
> for i in /usr/lib/*.a /usr/local/lib/*.a; do
> objdump --reloc $i 2>/dev/null | grep R_X86_64_32S >
/dev/null &&
echo $i;
> done
So, I tried it on my ubuntu system:
objdump --reloc /usr/lib/libdwarf.a 2>/dev/null | grep
R_X86_64_32S
00000000000000a4 R_X86_64_32S .rodata+0x0000000000000180
000000000000011f R_X86_64_32S .rodata+0x0000000000000198
00000000000004ba R_X86_64_32S .rodata+0x0000000000000180
00000000000004c0 R_X86_64_32S .rodata+0x0000000000000180
jeg@jeg-OptiPlex-GX620:~/OpenSpeedShop_ROOT$ objdump --reloc
/usr/lib/libiberty_pic.a 2>/dev/null | grep R_X86_64_32S
jeg@jeg-OptiPlex-GX620:~/OpenSpeedShop_ROOT$ objdump --reloc
/usr/lib/libiberty.a 2>/dev/null | grep R_X86_64_32S
00000000000000f5 R_X86_64_32S .rodata
00000000000004b4 R_X86_64_32S .rodata+0x00000000000000f0
000000000000071a R_X86_64_32S .bss+0x0000000000000080
000000000000074f R_X86_64_32S .bss+0x0000000000000080
To your knowledge is that the best way to check for fPIC
libraries?
That works; the arguably more robust approach is to build a sample
shared library that calls a method in libdwarf/libiberty/whatever
else and test compilation/linking. PIC is a side question to the
main one of "can we link against this from a shared library?".
Pretty straightforward but I haven't gotten to it yet.
And the BG/Q issues are not forgotten--they're in the queue and
will be resolved before we release, of course.
--bw
Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
|
|