From: Maxime D. <max...@et...> - 2008-11-29 12:52:24
|
Hi, On the website, the section "Linking With Your Application" explains how to build an executable with : c++ -o foo foo.C `libmesh-config --cxxflags --include --ldflags` This is fine on my installation. My question, surely trivial, is : How to build a libmesh static library to call foo functions in external programs ? Thanks, Maxime |
From: Benjamin K. <ben...@na...> - 2008-11-29 17:57:38
|
> On the website, the section "Linking With Your Application" explains > how to build an executable with : > > c++ -o foo foo.C `libmesh-config --cxxflags --include --ldflags` > > This is fine on my installation. > > My question, surely trivial, is : How to build a libmesh static > library to call foo functions in external programs ? I'm not sure why you need a static library to do this instead of a shared one, but at any rate $ ./configure --disable-shared ... will do what you want. -Ben |
From: Maxime D. <max...@et...> - 2008-11-29 21:10:46
|
Thank you for your answer. My explanation was incomplete. My problem comes from a second stage library, a library made on libmesh.so or libmesh.a [ ex: libfoo ] First I tried to make a library with example ex0 as in the tutorial : http://www.adp-gmbh.ch/cpp/gcc/create_lib.html The classic compilation with the makefile works perfectly but when creating the library, either I obtain "ar: -lz: No such file or directory" for a static library libex0.a or "segmentation fault (core dumped)" after compilation with shared libex0.so The segmentation fault seems to occur at instruction : libMesh::init(argc, argv); May be some libraries are not completely linked Maxime |
From: Maxime D. <max...@et...> - 2008-12-02 21:09:53
|
Hi, Things go better and better but it's not yet operational. I initially thought that the problem could come from library building, but it doesn't. The example 0 is used. First, the next line compiles and the exe is fine : c++ -o ex0 ex0.C `libmesh-config --cxxflags --include --ldflags` Second, we introduce an object step : c++ -c ex0.C -o ex0.o c++ -o ex0 ex0.o`libmesh-config --cxxflags --include --ldflags` When the original program is used [ system.add_variable("u",SECOND); ], execution returns : ERROR: Bad FEType.family= 134874400 [0] src/fe/fe_base.C, line 107, compiled Dec 2 2008 at 01:08:20 Aborted (core dumped) Else, when element are differently declared [ FEFamily elemFamily = LAGRANGE; Order elemOrder = FIRST; ElemType type = EDGE2; FEType fe_type(elemOrder,elemFamily); system.add_variable("u", fe_type); ] execution returns : [0] src/fe/fe_interface.C, line 381, compiled Dec 2 2008 at 01:09:46 Aborted (core dumped) May be my error is already known, If anyone has an idea, Thanks, Maxime |
From: Roy S. <roy...@ic...> - 2008-12-02 21:21:31
|
On Tue, 2 Dec 2008, Maxime Debon wrote: > May be my error is already known, I've never seen anything like it before... maybe vaguely similar, when out-of-date Makefile dependencies caused old object files to be linked against binary-incompatible newer code. When you compile with METHOD=dbg, do the errors manifest any differently/sooner? --- Roy |
From: Maxime D. <max...@et...> - 2008-12-04 16:21:11
|
Quoting Roy Stogner <roy...@ic...>: | out-of-date Makefile dependencies You were right, there was some conflict between libraries. This is the script I used to create an intermediate library on example 0 : ___________________________________________ c++ -fPIC -c ex0.C -o ex0.o c++ -shared -Wl,-soname,libex0.so -o libex0.so.1.0.1 ex0.o `libmesh-config --cxxflags --include --ldflags` sudo chmod 777 libex0.so.1.0.1 sudo mv *so* /usr/lib/ sudo ldconfig c++ -o ex0 -L. -lex0 ./ex0 ___________________________________________ This way, the example runs perfectly. By now, the objective is to call this or another library from R front end. I truely think it's possible to make a link between these tools but there is a constraint with libmesh::init(argc, argv). This last function is now deprecated but the initialisation problem remains the same. R extension with C or C++ code could be declared this way : ___________________________________________ double foo(double A, double B) { return A+B; }; extern "C" { void foo_R(double* output, double* A, double* B){ *output = foo(*A,*B); }; } ___________________________________________ With non libmesh code, this is fine The question is : How and where should libmesh::init(argc, argv) be called if foo depends on libMesh ? May be argc and argv could be fakes. At the moment the result is a segmentation fault. If someone has managed to build a bridge between libMesh and R, Thanks, Maxime |
From: Roy S. <roy...@ic...> - 2008-12-04 16:54:42
|
On Thu, 4 Dec 2008, Maxime Debon wrote: > By now, the objective is to call this or another library from R front end. > > I truely think it's possible to make a link between these tools but there is > a constraint with libmesh::init(argc, argv). This last function is now > deprecated but the initialisation problem remains the same. > > R extension with C or C++ code could be declared this way : > ___________________________________________ > > double foo(double A, double B) { return A+B; }; > > extern "C" { > void foo_R(double* output, double* A, double* B){ > *output = foo(*A,*B); > }; > } > ___________________________________________ > > With non libmesh code, this is fine > > The question is : > > How and where should libmesh::init(argc, argv) be called if foo depends on > libMesh ? I've never used R, but this bit of the manual seems to apply: "Various R functions in a package can be used to initialize and clean up. For packages without a name space, these are .First.lib and .Last.lib. (See Load hooks, for packages with a name space.) It is conventional to define these functions in a file called zzz.R" Allocate a singleton LibMeshInit object in the initialization function and destroy it in the clean up function. > May be argc and argv could be fakes. They can be fakes as far as we're concerned; just make argc=0 and GetPot will be happy with even a NULL argv. Your MPI implementation and PETSc might be stricter. --- Roy |