|
From: Stephen T. <st...@to...> - 2007-01-04 03:39:40
|
I am working on getting VEX to build with the automake, autoconf and libtool GNU tools. Right now I am coming down to a issue of linking. When I compile a tool, like memcheck, I am getting issues with linking memcheck with a shared library version of VEX. I did not see a reason why VEX should only be a static library. Who is the main point of contact on the valgrind build system? Stephen |
|
From: Julian S. <js...@ac...> - 2007-01-04 03:43:54
|
The reason vex is built statically is that valgrind is linked statically and without glibc. Allowing glibc and dynamic linking to be part of valgrind is a recipe for stability and portability problems and as a result of those concerns, about 2 years ago there was a transition to the current static linking and no use of libc support. J On Thursday 04 January 2007 03:39, Stephen Torri wrote: > I am working on getting VEX to build with the automake, autoconf and > libtool GNU tools. Right now I am coming down to a issue of linking. > When I compile a tool, like memcheck, I am getting issues with linking > memcheck with a shared library version of VEX. I did not see a reason > why VEX should only be a static library. Who is the main point of > contact on the valgrind build system? > > Stephen > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Stephen T. <st...@to...> - 2007-01-04 04:12:53
|
On Thu, 2007-01-04 at 03:54 +0000, Julian Seward wrote:
> The reason vex is built statically is that valgrind is linked statically and
> without glibc. Allowing glibc and dynamic linking to be part of valgrind is
> a recipe for stability and portability problems and as a result of those
> concerns, about 2 years ago there was a transition to the current static
> linking and no use of libc support.
>
> J
When I attempt to link my project library against the static libvex that
is installed I get messages about missing symbols from the VEX library.
That is why I was looking to make VEX a shared library. Here are the
undefined symbols:
g++ -O0 -g -o elf_reverse -lreverse -lboost_program_options -lboost_date_time -L/usr/local/lib/valgrind/x86-linux -lvex elf_reverse.o
/usr/local/lib/libreverse.so: undefined reference to `LibVEX_default_VexControl(VexControl*)'
/usr/local/lib/libreverse.so: undefined reference to `LibVEX_Init(void ( volatile*)(), void (*)(char*, int), int, unsigned char, VexControl*)'
/usr/local/lib/libreverse.so: undefined reference to `LibVEX_Translate(VexTranslateArgs*)'
/usr/local/lib/libreverse.so: undefined reference to `LibVEX_default_VexAbiInfo(VexAbiInfo*)'
/usr/local/lib/libreverse.so: undefined reference to `LibVEX_default_VexArchInfo(VexArchInfo*)'
collect2: ld returned 1 exit status
I made a shared library using automake, autoconf, and libtool from a set
of static helper library files. Which I linked as follows in my
Makefile.am:
lib_LTLIBRARIES = libreverse.la
libreverse_la_SOURCES =
libreverse_la_LIBADD = $(top_builddir)/src/api/libapi.la \
$(top_builddir)/src/data_types/libData_types.la \
$(top_builddir)/src/components/libComponents.la \
$(top_builddir)/src/infrastructure/libInfrastructure.la \
$(top_builddir)/src/io/libIO.la \
$(top_builddir)/src/meta/libMeta.la \
$(top_builddir)/src/cpus/libCPU.la
libreverse_la_LDFLAGS = -lxerces-c -lboost_filesystem-gcc
I can compiled against my project library if I comment out any use of
VEX variables or functions. Otherwise I get error messages in compiling
my test programs.
This is the command I am using:
g++ -O0 -g -o pe_reverse -lreverse -lboost_program_options -lboost_date_time -lvex pe_reverse.o
So far I am frustrated with trying to get this to link. Otherwise I may
need to ask OpenWorks LLC how I can use VEX separately from Valgrind so
I can make VEX a shared library. That way I will not polute the build
system. Any ideas as to why I am having a linking issue?
Stephen
|
|
From: Julian S. <js...@ac...> - 2007-01-04 04:31:37
|
> When I attempt to link my project library against the static libvex that
> is installed I get messages about missing symbols from the VEX library.
> That is why I was looking to make VEX a shared library. Here are the
> undefined symbols:
>
> g++ -O0 -g -o elf_reverse -lreverse -lboost_program_options
> -lboost_date_time -L/usr/local/lib/valgrind/x86-linux -lvex elf_reverse.o
> /usr/local/lib/libreverse.so: undefined reference to
> `LibVEX_default_VexControl(VexControl*)' /usr/local/lib/libreverse.so:
> undefined reference to `LibVEX_Init(void ( volatile*)(), void (*)(char*,
> int), int, unsigned char, VexControl*)' /usr/local/lib/libreverse.so:
> undefined reference to `LibVEX_Translate(VexTranslateArgs*)'
> /usr/local/lib/libreverse.so: undefined reference to
> `LibVEX_default_VexAbiInfo(VexAbiInfo*)' /usr/local/lib/libreverse.so:
> undefined reference to `LibVEX_default_VexArchInfo(VexArchInfo*)' collect2:
> ld returned 1 exit status
Ah. I know what's happening. Dynamic linking won't help. The vex build
system is just fine, and you can link in the vanilla libvex.a that it creates.
The problem is you are including libvex.h et al into C++ sources without
telling the C++ compiler that these functions are written in C. Hence
it uses C++ calling conventions which encode the types of the args in the
names in object files, and the final link fails.
The fix is easy. In your whatever.cpp, change
#include <libvex.h> // or whatever
to
#ifdef __cplusplus
extern "C" {
#endif
#include <libvex.h> // or whatever
#ifdef __cplusplus
}
#endif
In short you need to bracket any declarations that are intended to denote C
and not C++ with extern "C" { ... } so the C++ compiler knows that.
J
|
|
From: Stephen T. <st...@to...> - 2007-01-04 05:04:07
|
On Thu, 2007-01-04 at 04:41 +0000, Julian Seward wrote:
> Ah. I know what's happening. Dynamic linking won't help. The vex build
> system is just fine, and you can link in the vanilla libvex.a that it creates.
> The problem is you are including libvex.h et al into C++ sources without
> telling the C++ compiler that these functions are written in C. Hence
> it uses C++ calling conventions which encode the types of the args in the
> names in object files, and the final link fails.
Take a bow and go to the head of the class! I missed that. I will need
to make sure that when I am including a C header that it must have the
macro wrapper below or add it around my include. Thanks! I will clean up
my build of the VEX directory so that it only builds a static library
via automake and autoconf. Once that is done where do I post the patch?
Stephen
> #ifdef __cplusplus
> extern "C" {
> #endif
> #include <libvex.h> // or whatever
> #ifdef __cplusplus
> }
> #endif
|