Hi all,
We have a user that wants to build OpenSpeedShop with Intel compilers.
The compile/compiler is aborting when building Dyninst where it is
referencing TBB includes.
I wonder if anyone can see any issues with the compiler version, tbb
version or another thing that might be a problem.
Hi Ben, all,
There is a pull request submitted and waiting for approval:
https://github.com/spack/spack/pull/9728
Jim G
On 11/05/2018 11:57 AM, Benjamin Welton wrote:
Jim,
We are likely okay using either 2019 or 2018.6. So while Dyninst may
pull 2019 (which is apparently a week older than 2
Hi Ben,
No matter if I put the 2018.6 line before or after the 2019 line, 2019
will be built
because it is numerically higher than 2018.6. I believe that is the
logic spack uses.
class IntelTbb(Package):
"""Widely used C++ template library for task parallelism.
Intel Threading Buildi
2c35cbd76')
version('2017.1', '6c0fe8aa7bc911a85e8e522e620511b3')
version('2017', '9e7f9ea684ecf84ac74dcd3c6012cfa6')
version('4.4.6', '20e15206f70c2651bfc964e451a443a0')
version('4.4.5&
Hi all,
Because dyninst has a new TBB dependency mods to the spack
dyninst/package.py file are necessary.
I was able to build dyninst master (dyninst@develop spack version) with
spack using these mods to the dyninst/package.py file.
Do these fit with what the dyninst team has in mind?
We ne
Hi all,
Posting again without the library attached - the first email went to the
moderator list.
Jim G
On 10/26/2018 09:59 AM, Jim Galarowicz wrote:
Hi Dyninst team,
Here is the abort and output from running GEMM (mpi shoc cuda
benchmark) with our CUDA experiment osscuda.
It seems
Hi all,
I'm seeing this compile error with dyninst master on a IBM Power 9
system - (master as of Oct 15, 2018 5 pm CT.).
Thanks,
Jim G.
*==>* libiberty is already installed in
/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/libiberty-2.31.1-ignef7ht5g7phjabqd2252uhpfy7c2dr
*==>* *
Hi all,
I'm seeing this compile error with dyninst master on a IBM Power 9
system - (master as of Oct 15, 2018 5 pm CT.).
Thanks,
Jim G.
*==>* libiberty is already installed in
/home/jeg/spack/opt/spack/linux-centos7-ppc64le/gcc-4.8.5/libiberty-2.31.1-ignef7ht5g7phjabqd2252uhpfy7c2dr
*==>*
andia too. Why don’t you use a module with a newer compiler? Try
module load gnu
--
John Mellor-Crummey
(sent from my phone)
On Sep 15, 2018, at 6:24 PM, Jim Galarowicz wrote:
Hi all,
With the latest dyninst sources, I'm seeing these compile errors with gcc-4.9.3
at SNL.
Dynins
Hi all,
With the latest dyninst sources, I'm seeing these compile errors with
gcc-4.9.3 at SNL.
Dyninst compiled without error on my laptop with 7.2.1 gcc.
Thanks,
Jim G
grep -n emplace_back */*/*
symtabAPI/src/dwarfWalker.C:292: srcFiles->emplace_back("Unknown file","");
symtabAPI/src/dwa
t;https://aka.ms/ghei36>
*From:* Dyninst-api on behalf of
John Mellor-Crummey
*Sent:* Sunday, August 12, 2018 12:09:10 PM
*To:* Jim Galarowicz
*Cc:* dyninst-api@cs.wisc.edu
*Subject:* Re: [DynInst_API:] Compile error with master dyninst sou
Hi all,
I'm trying to build the master git version of dyninst, but I'm getting
this error.
Has anyone else hit this compile error?
Thanks,
Jim G
[ 12%] Built target symLite
[ 17%] Built target instructionAPI
[ 17%] Building CXX object
symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
Hi all,
I can run OpenSpeedShop fine on this application with the 9.3.2 version
of Dyninst and until recently the master git repository version too.
But, with the latest git master sources (as of yesterday morning) I'm
seeing this assert. The application is lulesh2.0.3 (mpi and openmp).
I
Hi all,
I'm trying to get a spack file change to the dyninst/package.py file
through the spack review process.
My changes say that versions 9.3.2 and below use libdwarf and future
versions use libdw.
Is that true?
Thanks,
Jim G
___
Dyninst-api
:* Wednesday, May 9, 2018 5:29:58 PM
*To:* Jim Galarowicz
*Cc:* Don Maghrak; dyninst-api@cs.wisc.edu
*Subject:* Re: [DynInst_API:]
Dyninst::ParseAPI::SymtabCodeSource::init_try_blocks(): Assertion
`!"WARNING: overlapping try blocks\n"' failed.
Hi Jim,
In theory, try blocks sho
ave any success.
Regards,
Sasha
*From:* Dyninst-api on behalf of
Xiaozhu Meng
*Sent:* Wednesday, May 9, 2018 5:29:58 PM
*To:* Jim Galarowicz
*Cc:* Don Maghrak; dyninst-api@cs.wisc.edu
*Subject:* Re: [DynInst_API:]
Dy
.
We can then determine whether there is indeed overlapping try blocks
or the parsing of try blocks is wrong.
Thanks,
--Xiaozhu
On Wed, May 9, 2018 at 3:06 PM, Jim Galarowicz <mailto:j...@krellinst.org>> wrote:
Hi all,
We have an abort that is showing a
Assert
Hi all,
We have an abort that is showing a
Assertion `!"WARNING: overlapping try blocks\n"' failed. from Dyninst.//
//The user stated that no core file was dropped.//
//The code is protected, so we don't have source code access or
execution access other than through the user.
Can anyone shed an
ese errors.
Thanks,
Jim G
On 04/13/2018 12:09 PM, Jim Galarowicz wrote:
Hi Xiaozhu,
Do you mean remove the CMakeCache.txt file and then touch
CMakeLists.txt and do a make to reconfigure cmake?
This is what I get when I do that. The build complains about no
/examples/unstrip files.
Than
or 1
[jeg@localhost dyninst-9.3.3]$
On 04/13/2018 09:20 AM, Xiaozhu Meng wrote:
Hi Jim,
I just recompiled the master branch from github. I saw the same
warning, but not the error. Can you try delete your existing cmake
cache file and then re-configure the cmake?
Thanks,
--Xiaozhu
On
Hi all,
I'm trying to build the latest git master branch version of dyninst and
I'm getting these build errors in codeCoverage.
Has anyone else seen this? I'm using the same cmake variables that I
did for 9.3.2, maybe that is the problem?
Thanks,
Jim G
[ 94%] Built target Inst
Scanning
libdwarf_imp and libelf_imp dependencies
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
On 10/03/2017 03:21 PM, Bill Williams wrote:
...okay, on further examination this means that cap_dwarf is somehow missing
from your platform
/03/2017 01:54 PM, Bill Williams wrote:
First step here is disabling cotire; it's great when it works but it seems to
have gotten very brittle on HPC systems. IIRC top of tree should have that as
an explicit cache variable. If not I'll make sure I push a patch up...
If that doesn't do the trick it shoul
ke sure I push a patch up...
If that doesn't do the trick it should just be a missing include I'd think.
____
From: Dyninst-api on behalf of Jim Galarowicz
Sent: Tuesday, October 3, 2017 1:47 PM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] DyninstAP
Hi all,
Just tried to build the top of tree (from a few minutes ago). I'm seeing
this error on a power 8 cluster.
Thanks,
Jim G
19%] Building CXX object
symtabAPI/CMakeFiles/symtabAPI.dir/src/Object-elf.C.o
In file included from
/home/jeg/OpenSpeedShop_ROOT/BUILD/p8-node.creativec.com/dy
this didn't go out with the merge. Same set of CMake flags, just point to
libdw and ditch libdwarf.
--bw
From: Dyninst-api on behalf of Jim Galarowicz
Sent: Tuesday, September 5, 2017 11:20 AM
To: dyninst-api@cs.wisc.edu
Subject: [DynInst_API:] Dynin
Hi all,
I downloaded the latest dyninst git tree sources this weekend and tried
to build on a power 8 cluster.
I'm using libdwarf 20170416 and elfutils-0.168, but I'm getting these
compile errors with
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC).
Are there any new libdwarf or elfutils
Hi Bill,
I found it - sorry for the bother.
git clone https://github.com/dyninst/testsuite.git
Jim G
On 05/17/2017 04:22 PM, Jim Galarowicz wrote:
Hi Bill,
Thanks! But, where is the test-suite? Is it a separate download
now? I couldn't find it on your downloads area.
Thanks
as deprecated for quite a few versions, and you should expect it to go away in
favor of Statement when 10.0 is official.
--bw
From: Dyninst-api on behalf of Jim Galarowicz
Sent: Wednesday, May 17, 2017 3:29 PM
To: dyninst-api@cs.wisc.edu
Subjec
Hi Bill, all,
We are trying to upgrade from Dyninst-9.2.0 to Dyninst-9.3.2 - forced
really because of Power 8 related Dyninst aborts with 9.2.0 that we hope
are fixed in the newer version.
We have a snippet of code that gets line number information, that now
does not compile with 9.3.2, but
Hi Bill, all,
I'm seeing this compile error with the default 9.2.0 version using Intel
15 compiler on Edison at NERSC.
> icc --version
icc (ICC) 15.0.1 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
jgalaro@edison05:/project/projectdirs/m888/jgalaro/OpenSpeedShop_RO
Hi all,
What would cause this message from Dyninst. I was running on a LANL
cluster, using Dyninst-9.2 for the first time.
libdwarf version was 20160507 from the libdwarf website.
Thanks,
Jim G
STOP
STOP
STOP
mrnet_commnode:
/p/home/galarowi/OpenSpeedShop_ROOT/BUILD/armstrong02/dyninst-
/src/dwarfWalker.C:#include "Type.h"
symtabAPI/src/parseDwarf.C:#include "Type.h"
dyninstAPI/src/BPatch_module.C:#include "symtabAPI/h/Type.h"// For
BPatch_type related stuff
dyninstAPI/src/BPatch_snippet.C:#include "symtabAPI/h/Type.h"
On 07/06/2016 11
-9.2.0/dataflowAPI/src/RegisterMap.C
(code 2)
make[2]: ***
[parseAPI/CMakeFiles/parseAPI.dir/__/dataflowAPI/src/RegisterMap.C.o]
Error 2
make[1]: *** [parseAPI/CMakeFiles/parseAPI.dir/all] Error 2
On 07/06/2016 12:42 PM, Jim Galarowicz wrote:
Hi Bill,
Adding Type.h didn't change
/src/dwarfWalker.C:#include "Type.h"
symtabAPI/src/parseDwarf.C:#include "Type.h"
dyninstAPI/src/BPatch_module.C:#include "symtabAPI/h/Type.h"// For
BPatch_type related stuff
dyninstAPI/src/BPatch_snippet.C:#include "symtabAPI/h/Type.h"
On 07/06/201
ker.C:1270:
undefined reference to `Dyninst::SymtabAPI::typeRef*
Dyninst::SymtabAPI::typeCollection::addOrUpdateType(Dyninst::SymtabAPI::typeRef*)'
make[2]: *** [symtabAPI/libsymtabAPI.so.9.2.0] Error 1
make[1]: *** [symtabAPI/CMakeFiles/symtabAPI.dir/all] Error 2
make: *** [all] Error 2
/
Hi Bill, Dyninst team,
I'm trying to compile Dyninst for the Intel Phi and got the error below.
PBS maia97 28> icc -v
icc version 15.0.0 (gcc version 4.3.0 compatibility)
Is this due to the very old gcc that the Intel compiler is using under
the hood for cxx11 checks, etc.?
Thanks,
Jim G
C
Hi Bill, all,
I came across this today when trying to build dyninst on a new Cray at LANL.
I get the fatal error below, but I'm not sure why and then it looks like
it compiles the file anyway.
I guess I'm looking for some guidance on this issue.
We are building for the compute node in this com
o, I guess I need to look into how to get sampling/timing results on
the function level of my test application.
Thanks again,
Mike
On Mon, Jan 25, 2016 at 11:40 AM, Jim Galarowicz <mailto:j...@krellinst.org>> wrote:
Hi Mike,
You could also try setting OPENSS_MPI_IMPLEME
On 01/13/2016 09:49 AM, Josh Stone wrote:
On 01/13/2016 08:40 AM, Jim Galarowicz wrote:
[ 10%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
/nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112/dyninst-9.1.0/common/src/linuxKludges.C(1032):
error: no instance of
Hi Dyninst team,
I ran into some build problems with the Dyninst-9.1 release.
I'm on a platform that has an old gcc compiler that doesn't have support
for C++11 auto (see just below) and there are no gcc alternatives. I
will check into seeing if the laboratory will upgrade gcc or offer a
modu
Hi Bill,
I've attached the binary.Let me know if you don't get it. I know
you used to protect against executable attachments.
Thanks,
Jim G
On 12/03/2015 09:11 AM, Bill Williams wrote:
On 12/02/2015 10:16 PM, Jim Galarowicz wrote:
Hi Bill, team,
I was trying to run Ope
Hi Bill, team,
I was trying to run OpenSpeedShop using Dyninst 9.0.3 (top of tree) on
babbage (NERSC Intel MIC testbed) and got the core dump and traceback
while OSS attempted to find the loops in the application.
I can send more details. Maybe you can see something from the traceback.
As th
++11 support for "auto_ret_type"
On 11/25/2015 03:09 PM, Knapp, Rashawn L wrote:
Jim,
On our HSW-EP and on our KNL install of Dyninst we set the $PLATFORM
to x86_64-unknown-linux2.6.
Regards,
-Rashawn
*From:*Jim Galarowicz [mailto:j...@krellinst.org]
*Sent:* Wednesday, Novembe
Hi Bill,
Would I have to set PLATFORM? When I echo "PLATFORM=$PLATFORM" before the
cmake command, it is null/empty.
Thanks
Jim G
running cmake for Intel mic
platform=
PLATFORM=
On Wed, Nov 25, 2015 at 1:37 PM, Jim Galarowicz wrote:
> Hi Bill,
>
> I added the -std=c
NC -DLIBELF_LIBRARIES=$LIBELF_LIBNAME
-DLIBELF_INCLUDE_DIR=$LIBELFINC -DPATH_BOOST=$DYNINST_BOOST_ROOT
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME -DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME
else
I'm getting the echo, so I know we are getting into this cmake command.
Jim G
On 11/25/2015 08:56 AM, B
ay, November 24, 2015 9:13 AM
To: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] Dyninst building with Intel compilers?
On 11/23/2015 07:01 PM, Jim Galarowicz wrote:
Hi Bill, Dyninst team,
I forgot to include how I'm calling cmake. Maybe this isn't the best
way to do it?
To: dyninst-api@cs.wisc.edu
Subject: Re: [DynInst_API:] Dyninst building with Intel compilers?
On 11/23/2015 07:01 PM, Jim Galarowicz wrote:
Hi Bill, Dyninst team,
I forgot to include how I'm calling cmake. Maybe this isn't the best
way to do it?
export cc=icc
exp
IBNAME
-DLIBDWARF_INCLUDE_DIR=$LIBDWARFINC -DLIBELF_LIBRARIES=$LIBELF_LIBNAME
-DLIBELF_INCLUDE_DIR=$LIBELFINC -DPATH_BOOST=$DYNINST_BOOST_ROOT
-DIBERTY_LIBRARIES=$LIBIBERTY_LIBNAME -DIBERTY_LIBRARY=$LIBIBERTY_LIBNAME
Thanks,
Jim G
On 11/23/2015 04:13 PM, Jim Galarowicz wrote:
Hi Bill, Dyn
Hi Bill, Dyninst team,
Does Dyninst build with Intel compilers? I'm trying to build on an
Intel MIC platform but I can't get by the C++11 support checks.
Thanks for any advice. This is the top of tree source code.
Thanks,
Jim G
~/babbage/OpenSpeedShop_ROOT/BUILD/bint01 ~/babbage/OpenSpe
)
);
}
}
retval.push_back(info);
} // l
} // f
} // m
return retval;
}
On 09/11/2015 02:42 PM, Jim Galarowicz wrote:
Hi all,
I'm trying to use the new loop API to find
(c)c ## UL
305# else
306# define UINT64_C(c)c ## ULL
307# endif
308
309/* Maximal type. */
310# if __WORDSIZE == 64
311# define INTMAX_C(c)c ## L
312# define UINTMAX_C(c)c ## UL
313# else
314# define INTMAX_C(c)
Hi Bill, Josh,
That worked. I was able to build successfully.
Thanks for the quick response.
Jim G
On 09/11/2015 04:01 PM, Bill Williams wrote:
On 09/11/2015 04:00 PM, Josh Stone wrote:
On 09/11/2015 01:46 PM, Bill Williams wrote:
How on earth does git archive not know how to tar.gz somethi
Hi Bill,
On 09/11/2015 03:46 PM, Bill Williams wrote:
On 09/11/2015 03:40 PM, Jim Galarowicz wrote:
Hi all,
I'm trying to build the latest git version of dyninst on a X86_64
cluster.I just did the git clone.
The build is cruising along until it shows this tar.gz error
(below).
Hi all,
I'm trying to build the latest git version of dyninst on a X86_64
cluster.I just did the git clone.
The build is cruising along until it shows this tar.gz error (below).
Does anyone know what might be wrong?
I'm using cmake-3.2.2 and gcc version 4.8.2 20140120 (Red Hat 4.8.2-15)
Thanks Bill!
I'll give it a try on the ARM platform I'm building on.
Thanks,
Jim G
On 08/21/2015 03:40 PM, Bill Williams wrote:
Jim reported that when building things other than Dyninst, the
preprocessor definitions from the Dyninst build system weren't
present, and so we had no version infor
ve Xi SONG
Subject: Re: [DynInst_API:] Dyninst on aarch64 ARM system doesn't build (for me)
On 08/19/2015 02:35 PM, Jim Galarowicz wrote:
Hi all,
I downloaded the git repository version of Dyninst a few minutes ago and
tried to build on an ARM based system (64-bit aarch64).
It looks like
Hi all,
I downloaded the git repository version of Dyninst a few minutes ago and
tried to build on an ARM based system (64-bit aarch64).
It looks like Dyninst is looking for a file named:
src/RTthread-aarch64-asm.S but can't find it.
Can anyone help with this issue?Maybe my cmake line is
in
seconds.
255.20 88.270900 nbody.mic
33.73 11.666840 libmpi.so.12.0
0.14 0.048424 libc-2.14.90.so
0.03 0.010377 libmpifort.so.12.0
0.01 0.003459 pcsamp-rt-offline.so
openss>>
openss>>quit
On 07/28/2015 11:4
identifier is: -x 1
(There are no objects specified for the basic Detail report.)
On 07/27/2015 05:14 PM, Jim Galarowicz wrote:
On 11/12/2014 03:36 PM, Bill Williams wrote:
On 11/12/2014 03:33 PM, Jim Galarowicz wrote:
Yes, I have to try to find the target version of elf.h. The host one
mus
sicBlockLoop::getLoopEntries(BPatch_Vector &e);
The new interface returns the number of entry blocks of this loop and
the entries blocks are returned as the output parameter.
On Tue, Jul 28, 2015 at 8:42 AM, Jim Galarowicz wrote:
Hi all,
I've downloaded the git source version of dyninst a
Hi all,
I've downloaded the git source version of dyninst and built it on NASA's
pfe machine and my laptop in an attempt to run it on Intel MIC
binaries. The 8.2.1 asserts in switches related to the architecture type.
However, I ran into a compile error with our loop code:
[ 16%] Buildin
Hi Dyninst team,
Does anyone in the Dyninst group have access to Titan at ORNL?
If so, I'm wondering if someone could try building Dyninst there. I
believe I'm building Dyninst in the same way we do on all other Cray's
where we don't see this problem.
So, it would be good to have a sanity chec
Hi Dyninst team,
We have encountered an error on the NERSC babbage Intel MIC test bed.
The machine is down right now, but I can get more information when it
comes up, if you need it.
Looks like an unexpected type of elf construct was encountered. This
code was compiled with the Intel compilers
Hi Dyninst team,I must be an exception to the rule, but I've run into another build issue. This one on a DOD cray system.I've tried with gcc-4.3.4, gcc-4.8.0, gcc-4.8.2, and gcc-4.9.1. These are the available compilers on this system.I'm using boost-1.53.0Any ideas on how to fix this one? Is th
define __UINT32_MAX__ 4294967295U
#define __INT64_C(c) c ## L
Thanks,
Jim G
On 10/18/2014 07:50 AM, Dave Goodell wrote:
On Oct 18, 2014, at 12:17 AM, Josh Stone wrote:
On 10/17/2014 08:17 PM, Jim Galarowicz wrote:
Hi Josh,
Thanks for the reply. I haven't been able to figure anything out. This
mus
gt;
!gre
grep stdint *.h
I'm dead in the water on Titan.I've built Dyninst here many times.
I tried the pre-release 8.2 version I had and that fails in the same way.
They have upgraded the system since then.
I'll try again tomorrow.
Thanks,
Jim G
On 10/17/2014 02:58 PM,
/dyninst-8.2/common/src/Types.h:159:18:
error: 'INT32_MIN' was not declared in this scop
On 10/17/2014 09:22 AM, Jim Galarowicz wrote:
Hi,
I'm getting these types of errors when trying to build Dyninst on the
ORNL Titan Cray.
It looks to me like this shouldn't happen, as the IN
Hi,
I'm getting these types of errors when trying to build Dyninst on the
ORNL Titan Cray.
It looks to me like this shouldn't happen, as the INT32_MAX and other
defines are in /usr/include/stdint.h and Types.h includes stdint.h.
Any ideas on why these errors are showing up?
Thanks,
Jim G
/cc
Hi Dyninst team,
I'm getting these compile errors on spirit at a DOD site. The compiler is
4.7.3.
What level of boost is needed to build Dyninst? This system has boost-1.41:
ash-4.1$ rpmq boost
perfboost-1.10-sgi710r6.rhel6.x86_64
boost-regex-1.41.0-18.el6.x86_64
boost-1.41.0-18.el6.x86_64
b
txt:add_library (dyninstAPI_RT_m32 SHARED ${SRC_LIST_mabi})
CMakeLists.txt:add_library (dyninstAPI_RT_m32_static STATIC
${SRC_LIST_mabi})
Is there a way and I'm missing it?
Thanks,
Jim G
On 03/26/2014 02:37 PM, Bill Williams wrote:
On 03/26/2014 01:36 PM, Jim Galarowicz wrote:
Hi all,
If I do
Hi Josh, Bill, all,
I switched back to 8.1.2 on rzmerl for this particular build and it
seems to be working.
I will try the new version again when the new code becomes available to me.
Thanks,
Jim G
On 06/19/2014 11:48 AM, Josh Stone wrote:
On 06/19/2014 11:34 AM, Jim Galarowicz wrote
Hi all,
Currently, I'm using the official release for 8.2.
Will this get the latest version for me to use?
git clone http://git.dyninst.org/dyninst.git
Thanks,
Jim G
On 06/19/2014 11:28 AM, Josh Stone wrote:
On 06/19/2014 11:15 AM, Matthew LeGendre wrote:
On Thu, 19 Jun 2014, Josh
Hi Josh,
It is cmake-2.8.6. I have to use packages coming out of the kestrel
application package area. I'm not sure if cmake is one of the packages
in that area.
Thanks for the tips on the build. I had to focus on work related to
the ORNL Cray yesterday, so I didn't get to try some of the
Hi all,
I'm getting a build error on rzmerl at LLNL when trying to build the
release version of 8.2.
The message I'm getting:
Linking CXX shared library libcommon.so
/usr/bin/ld: cannot find -lLINK_PRIVATE
collect2: ld returned 1 exit status
make[2]: *** [common/libcommon.so.8.2.0] Error 1
ma
e[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/etijskens/software/openspeedshop-release-2.1/BUILD/bert-MacBookPro-ubuntu/openspeedshop-2.1'
> make: *** [all] Error 2
> error: Bad exit status from
> /home/etijskens/software/openspeedshop-release-2.1/I
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
instal
Hi all,
I built my own binutils and the Dyninst build worked.
Just thought I'd provide that status.
Thanks for your time!
Jim G
On Mar 26, 2014, at 11:36 AM, Jim Galarowicz wrote:
> Hi all,
>
> If I do a module purge, that apparently gets rid of the intel library
>
mmon.dir/src/parseauxv.C.o
[ 5%] Building CXX object
common/CMakeFiles/common.dir/src/addrtranslate-sysv.C.o
[ 6%] Building CXX object
common/CMakeFiles/common.dir/src/addrtranslate-auxv.C.o
[ 6%] Building CXX object
common/CMakeFiles/common.dir/src/addrtranslate-linux.C.o
Linking CXX share
ble code (even though it's all linux/x86_64).
>
> Dyninst's CMake is being handed the backend compiler, then testing the
> compiler on the frontend and finding it broken. Depending on whether you
> want to build Dyninst for the frontend or backend you need to:
>
> - U
Hi,
I'm now trying to build Dyninst 8.2 on an SGI ICE system. But I'm getting this:
CMake Error at
/work1/app/gnu/platforms/x86_64/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61
(message):
The C compiler "/app/gmpapp/gcc/platform/gcc-4.7.3/bin/gcc" is not able to
compile a simple tes
Hi Bill,
Ok. I fell back to 8.1.2 and it built on the BG/Q FE.
Thanks,
Jim G
On 03/24/2014 09:03 AM, Bill Williams wrote:
Jim--
I'm going to be poking at a bare Dyninst build on useq today, as it
happens. I'll let you know what I find out.
--bw
On 03/24/2014 09:47 AM, Jim
Hi all,
I'm trying to build DyninstAPI on the FE of a BG/Q. I'm getting an
assembly error.
Can anyone see if I'm doing something wrong or if there is a build issue
in Dyninst?
Thanks,
Jim G
+ exit 0
VAMPIRTRACE BUILT SUCCESSFULLY.
Build dyninst?
Build-RPM command-line argument #1 = dyn
, Jim Galarowicz wrote:
Hi Bill,
In response to your email (thanks Josh and Matt), I think I'm passing in
the correct parameters.
Unless I'm supposed to pass something different than this, below:
CMakeCache.txt:IBERTY_LIBRARY:FILEPATH=/usr/lib64
You need the whole file path
configuration explicitly requests the GNU demangler instead. And if we
can't find one we'll try to download binutils and build it.
Do you have the cmake output from when you configured Dyninst? That
should let me know what we did/didn't try to do.
--bw
On 03/10/2014 10:36 PM,
angle
00063b30 T _Z16P_cplus_demanglePKcbb
00071260 r _ZZ16P_cplus_demanglePKcbbE19__PRETTY_FUNCTION__
Thanks,
Jim G
On 03/10/2014 09:18 PM, Jim Galarowicz wrote:
Hi Dyninst team,
I was wrong about it working on Fedora 19. It fails there in the same
way as on Fedora 20. I need to
Hi Dyninst team,
I was wrong about it working on Fedora 19. It fails there in the same
way as on Fedora 20. I need to beef up the build failure detection.
Thanks,
Jim G
On 03/10/2014 08:36 PM, Jim Galarowicz wrote:
Hi Dyninst team,
I'm looking for some advice on how to resolve,
Hi Dyninst team,
I'm looking for some advice on how to resolve, in a reasonable fashion a
linking error I'm seeing.
I'm trying to link the OpenSpeedShop utility: osswrapper using the new
8.2 git tree dyninst but I'm getting an undefined from libcommon for
cplus_demangle.
I'm seeing the iss
Hi Matt,
Your patch fixes the build issue I was seeing!
Thanks!
Jim G
On 03/07/2014 10:30 AM, Matthew LeGendre wrote:
On Fri, 7 Mar 2014, Josh Stone wrote:
On 03/07/2014 07:48 AM, Jim Galarowicz wrote:
We (OSS team) have always set the libdir to lib64 on x86_64 machines
and
installed the
for your help! Matt sent me a patch that I'm trying now.
Jim G
On 03/07/2014 09:07 AM, Josh Stone wrote:
On 03/07/2014 07:48 AM, Jim Galarowicz wrote:
Hi Dyninst team,
When I tried to build the existing 8.1.2 version on Fedora 20 with
gcc-4.8.2 I encountered some compile errors in procco
90 matches
Mail list logo
