I am trying to run a plug in I have made that makes use of the multicomponent and simple_compressible plug_in files (I’m aware that this has been done for 2.4.0 but I’m missing some dependencies for it in 2.1.0) and I get an error message when trying to load up the Additional Library in the parameter file. The message reads:
{
The violated condition was:
handle != nullptr
Additional information:
Could not successfully load shared library <./plugins/material_models/plug_in_test/libmy_plug_in.so>. The operating system reports that the error is this: <./plugins/material_models/plug_in_test/libmy_plug_in.so: undefined symbol: _ZN6aspect13MaterialModel23register_material_modelILi2EEEvRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_PFvRN6dealii16ParameterHandlerEEPFPNS0_9InterfaceIXT_EEEvE>.
}
At first I thought I’d made an error in my plug-in file, but testing the simpler_with_crust plug-in cookbook from aspect 2.1.0 throws up a similar error message. Is there potentially something wrong with the cookbook file that throws this error up (my plug in design is based upon this one), or is it something with the aspect version itself? From the looks of it the error came from the main.cc file in the aspect source code.
Many thanks for your help
Kind regards,
Alex
Alex:
that’s an odd error that I can’t make sense of. From your description with version numbers, there is question worth asking though: Are you compiling your plugin against the same version of ASPECT as the one you’re trying to load it with?
Best
Wolfgang
It’s the same version of Aspect, yes. I only mentioned it because the github page is 2.4.0 and just thought I’d clarify.
The plug in is from the 2.1.0 repository and compiled to the version of Aspect I’ve got running.
Kind regards,
Alex
Hi Wolfgang,
Found the culprit. It was an older version of gcc that compiled the plug-in wrong.
Kind regards,
Alex
Alex – ah, great! Glad to hear you found what the problem was!
Best
W.
Hi Wolfgang,
Sorry, I’ve run into another issue which I’m not sure will be the cause. I’m trying to load a library I compiled but it’s saying that the Additional Shared libraries wasn’t declared in the current subsection. I used the same compiling methods for the free surface cookbook and that’s working. My guess is it’s something in my plug-in file but I’m unsure. I was wondering if this is something you may have run into before?
Kind regards,
Alex
Alex: This looks like you’ve got an invalid input file – it complains about the format of the input file, not about the specifics of the shared library. Can you share how your input file looks like?
Best
W.
Hi Wolfgang,
I’ve attached a picture of the top section of the input file, as I doubt further sections will have a problem.
My confusion is mainly in the fact it states it’s loading the library it followed by the error, implying that it is in the process of loading the library.
My guess is it was something in my plugin when I copied over some of the code from cookbooks and the source code. I created a new plugin and wrote out the file manually line by line, taking more care this time, and it compiled and worked with the parameter file. Could a problem in the C++ file potentially cause this? While I did get what I wanted working, I want to figure out what the problem was to avoid it in the future.
Thanks for your help,
Alex
Alex: I am confused by the fact that the error message shows line 4, whereas your screen shot shows that the parameter is set in line 3. Is this both correct?
Best
W.
Hi Wolfgang,
Sorry, I should of noticed that and clarified. The original error message was the first time it appeared so I took a screenshot to keep a record of the error. I then changed the line number of the “set Additional shared libraries” parameter to see if that had any effect, which it didn’t. May seem like a silly thing to check, but I wanted to be sure. Other than the line number, nothing in the parameter file has changed since I ran the program originally.
Thanks,
Alex
Alex: Can you move the line with the “Additional shared libraries” below some of the other parameters? I’m wondering whether it is that particular parameter that it complains about, or simply the first parameter it sees.
I’m also wondering whether you are using a different line ending convention than your system expects.
Best
W.
Hi Wolfgang,
I changed the “set Additional shared libraries” parameter to line 12 and the “set Dimension” (line 5) was now throwing up the error. However, I then changed shared libraries parameter (still on line 12) to my working plugin location and that started running the program. Does Aspect read through the entire parameter file first to look for, then assign, the new library location? If so, would the different new line convention in the plugin carry over to parameter file which then would throws up the error?
Thanks,
Alex
Alex:
I have to admit that I don’t understand what you mean in your last sentence with “the different new line convention in the plugin carry over to parameter file”. But it is true that ASPECT first reads through the entire input file to (only) find the line(s) that indicate which libraries to load, loads these libraries, and then reads through the entire input file again to actually read the parameters. This procedure is necessary because the plugin may be declaring variables that it will then want to read from the input file.
Best
WB
Hi Wolfgang,
Thank you for your help. It’s helped me understand the problem a bit more and how Aspect runs in general.
My thoughts on what the problem was:
- ASPECT reads the parameter file using a default convention/formatting/interpreter to initially read through and load the plugin library.
- The plugin library used a different method for the formatting, which ASPECT then uses to read the library into the parameter file.
- When ASPECT goes back to read the parameter file again, it used this new interpreter method from the plugin which couldn’t read what was written in the parameter file, as it was written using the default (initial) formatting method, therefore throwing up the error message.
(Interpreter probably isn’t the right word to use here, but I hope it conveys what I’m trying to get across)
I think this is why the original output message said it was loading the library (on the initial run) and then produced the error (on the second run). I may not have grasped the entirety of the problem, but I think I understand it enough to avoid it in the future.
Apologies, if any of my questions were fairly basic, as my experience is in python and bash, and C++ is much more complex.
Again, thank you for your help, it’s been greatly appreciated,
Kind regards,
Alex
Alex:
I still don’t understand what caused the problem, partly because I don’t know what you mean when you say “I then changed shared libraries parameter to my working plugin location”. But is it correct that you now have a working configuration?
Best
WB
Hi Wolfgang,
Yes, I do have a working configuration, I rewrote the plugin word for word in a separate plugin file, which has solved the issue I was having.
In the original plugin file (the one that didn’t work) I had copied over some of the included files at the top of the file and the explicit instantiations at the bottom from the Aspect source files in the repository. This was an attempt to save time and not have to write everything from scratch (Which in the end I had to do anyway). I think that’s where the problem came from as perhaps the code I copied over may have been formatted differently to what Aspect was expecting. Again, I’m not entirely sure, but writing it completely from scratch did solve my problem.
Kind regard,
Alex
