On Wed, 11 Oct 2017, simone via Libmesh-users wrote:
I apologize if this is not the right place to report this problem,
This is the right place to report it, yes. We had to fork from the original GetPot after newer versions from the original software author stopped using an open source license, so at this point libMesh GetPot is full of new features (such as the namespace option) and probably new bugs, none of which will be relevant upstream.
I'm having trouble using GetPot library (not the one included in libMesh installation), paired with Libmesh. I have isolated the problem in the attached pack,
I'm afraid our email list typically strips attachments. I think I understand the problem from your description alone, but if I'm wrong then you could send to my email address specifically with the attachment.
when running it I have a segfault error at the exit of the program. I know there's a conflict beetwen getpot class definitions, but I don't understand why this occur even without including the libmesh getpot.h header.
Probably because it's a link-time error? Although all the GetPot functions are declared inline, that keyword doesn't actually *force* the compiler to inline things! Glancing at my gcc 7.2 libMesh build, for instance, "nm --demangle libmesh_opt.so | grep GetPot" shows me literally dozens of symbols corresponding to compiled GetPot functions. In practice, IIRC this means that the linker will pick one version or the other of each of those symbols when it seems them multiply-defined in different libraries. If a particular function (in your case, probably the destructor) is chosen from version A but ends up dealing with a class layout defined by version B, then it's going to try to look for member variables in the wrong places and the result will be a disaster. In theory, even if you get lucky, you shouldn't bet on it. The C++ standard says that you can have more than one definition of an inline function in your program only so long as all definitions are *identical*; when you include the same function multiple times with different definitions, the result is undefined.
I'm forced to use GetPot library in my program, I guess
The original author's version of it, you mean?
one possible solution could be to install libMesh library with the variable GETPOT_NAMESPACE defined, but I'd like to avoid it because my code is part of a library that can be delivered to external users using their standard installation of libMesh, and I can't force them to recompile their installed package. Is there another possible solution?
Since the C++ standard says you can't have two different definitions of the same function in the same program, you've logically only got four possibilities, and none of them look like great options. 1) Use one definition: use the libMesh GetPot. I assume from "forced" that this isn't an option. 2) Use two different functions. This is what libMesh was trying to enable via the GETPOT_NAMESPACE option. In hindsight I now see that we obviously should have defaulted that to "libMesh" rather than undefined, in our own usage... but if you have external users then it's probably too late for you for us to do that now. If I'm wrong about that let us know. Conversely, even if the original GetPot author hasn't added the same functionality, it wouldn't be hard for you to patch in manually... but I assume if you're "forced" to use his GetPot then you're probably not allowed to modify it either? 3) Use two different programs. The part that needs one GetPot communicates with the part that needs the other via a pipe or shared memory or some such. This is almost certainly too much work. 4) Use something outside the C++ standard. If you're on a system that gives you additional standards regarding symbol resolution, then you might possibly make use of those, whether it's via tricks with link order, manually limiting symbol exports, linker "version scripts", etc. The best introduction I can find quickly is here: https://holtstrom.com/michael/blog/post/437/Shared-Library-Symbol-Conflicts.html
Another question, about public method: libMesh::GnuPlotIO::write(fname) It seems to do nothing but raising an exception,
What exception? From what line? These are very important details.
and there's no way to avoid it. Is this the expected behaviour?
Definitely not in general.
Is there a way to print a 1d mesh on a gnuplot readable file as the method is depicted to do in the class documentation?
I certainly believe so. Four of our example codes do it, and I do see gnuplot_script and gnuplot_script_data output files for each of them in my build directory from "make check" yesterday. Do those work for you or throw the same exception? --- Roy ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
