Failed to create shared library with wx and STL, "multiple definition" error? - stl

I tried to build a shared library using wx and STL, and failed in an error of "multiple definition of". Please refer to:
https://code.google.com/p/gppanel/issues/detail?id=7
The declaration of wxPointListNode is not found in the sources. The suspicious lines are like these:
include/mathplot.h:85:WX_DECLARE_LIST(wxPoint, PointList);
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
include/gpLineLayer.h:16:typedef std::deque<mpPointLayer*> mpPointList_t;
What the problem is?

Without the actual code this is just a guess, but I suspect that
include/mathplot.h:87:WX_DEFINE_LIST(PointList);
generates the full definition of PointList, including a non-templated method wxPointListNode::DeleteData. mathplot.h is included by all of the .cpp files (gpPanel.cpp, gpSeries.cpp, and baseData.cpp). Each cpp file is compiled into a .o file, so each has its own definition of DeleteData, and when you try to link the .o files together into lib/libgpPanel.so the linker issues the errors you're reporting.
The definition of the method needs to be in its own cpp file that's compiled and linked in.

All wxWidgets methods with DEFINE in their name expand into a definition of something and a definition can only be used once in a module, so it typically can't appear in a header file (unless you can guarantee that it's included by only a single source file). So just don't put it there.
Moreover, if this is your code, you should avoid using the legacy WX_DECLARE_LIST macro at all and just use std::list<> or std::vector<> instead. Or, if you really want to use only wx (which can only be important if you are targeting some embedded platform without good STL implementation), then use wxVector<>.

Related

Compile file with two separate libraries in Cython

I wrote a library in Cython that has two different "modes":
If rendering, I compile using GLFW.
If not rendering, I compile using EGL, which is faster, but I have not figured out how to render with it.
What is the recommended way to handle this situation?
Right now, I have the following directory structure:
mujoco
├── __init__.py
├── simEgl.pyx
├── simGlfw.pyx
├── sim.pxd
└── sim.pyx
simEgl.pyx contains EGL code and simGlfw.pyx contains GLFW code. setup.py uses an environment variable to choose one or the other for the build.
This works ok, except that I need to recompile the code every time I want to switch between modes. There must be a better way.
Update
I agree that the best approach is to simultaneously compile two different libraries and use a toggle to choose which one to import. I already do have a base class in sim.pyx with shared functionality. However this base class must itself be compiled with the separate libraries. Specifically, sim.pyx depends on libmujoco.so which depends on either GLFW or EGL.
Here is my exhaustive search of possible approaches:
If I do not compile an extension for sim.pyx, I get ImportError: No module named 'mujoco.sim'
If I compile an extension for sim.pyx without including graphics libraries in the extension, I get ImportError: /home/ethanbro/.mujoco/mjpro150/bin/libmujoco150.so: undefined symbol: __glewBlitFramebuffer
If I compile an extension for sim.pyx and choose one set of graphics libraries (GLFW), then when I try to use the other set of graphics libraries (EGL) this does not work either unsurprisingly:
ERROR: GLEW initalization error: Missing GL version
If I compile two different versions of the sim.pyx library, one with one set of libraries, one with the other, I get: TypeError: unorderable types: dict() < dict() which is not a very helpful error message, but appears to result from trying to share a source file between two different extensions.
Something like option 4 should be possible. In fact, if I were working in raw C, I would simply build two shared objects side by side using the different libraries. Any advice on how to get around this Cython limitation would be very welcome.
(This answer is just a summary of the comments with a bit more explanation.)
My initial suggestion was to create two extension modules defining a common interface. That way you pick which to import in Python but be able to use them in the same way once imported:
if rendering:
import simGlfw as s
else:
import simEgl as s
s.do_something() # doesn't matter which you imported
It appears from the comments that the two modules also share a large chunk of their code and its really just the library that they're linked with that defines how they behave. Trying to re-use the same sources with
Extension(name='sim1', sources=["sim.pyx",...)
Extension(name='sim2', sources=["sim.pyx",...)
fails. This is because Cython assumes that the module name will be the same as the filename, and so creates a function PyInit_sim (on Python 3 - Python 2 is named slightly differently but the idea is the same). However, when you import sim1.so it looks for the function PyInit_sim1, fails to find it, and gives an error.
An easy way round it is to put the common code in "sim.pxi" and use Cython's largely obsolete include mechanism to textually include that code in sim1.pyx and sim2.pyx
include "sim.pxi"
Although include is generally no longer recommended and cimport is preferred since it provides more "Python-like" behaviour, include is a simple solution to this particular problem.

Doxygen FULL_PATH_NAMES does not generate full paths in file names

I have two libraries libA and libB.
libA contains a file Action.h
libB contains a file action.h
I want to generate doxygen documentation in the same output directory for both libraries. This directory is to be used in Windows, for which action.html and Action.html is unfortunately considered to be the same file. To prevent this clash, I wish to render the generated files unique by prepending their path names to them.
Therefore, I set FULL_PATH_NAMES to YES.
I expect to see something like libA_Action.html and libB_action.html when I generate the documentation, but I don't! I still see Action.html and action.html. Its as if the FULL_PATH_NAMES parameter does nothing at all. Do I also need to set some other parameter in the Doxyfile to make the FULL_PATH_NAMES parameter work correctly?
You're probably running doxygen twice - one time for each library. If that is the case, doxygen isn't aware of the fact that it might clash with an output from another run, so when it find an existing file, it assumes that it is leftover from a previous run, and overrides it.
Setting FULL_PATH_NAMES doesn't help, as doxygen has no idea that multiple libraries exist, so, as far as doxygen is concerned, the prefix is identical to all files, so even when you adding a force it, it adds nothing (That's probably a bug).
The solution to your problem is setting both libraries as inputs to the same doxygen project.
You can do it by setting INPUT to multiple folders in the configuration file:
INPUT = ...bla\Lib1 \
...bla\Lib2

Sharing source between 2 projects?

I have a project containing a big package "global" of classes which is designed for Web, I need to share these classes with a new mobile project, but when i add them with :
Properties -> Flex Build Path -> Source path -> Add Folder
they start appearing with index [source path] before the package name, and since them Flash Builder start trowing error messages :
"A file found in a source-path must have the same package structure '', as the definition's package, 'global'."
How can i fix this issue ?
As we've discussed in the comments, I think it would be a better approach to compile your "global" classes into a library (.swc).
You were concerned about loading unnecessary classes: when you link to a library as 'merged', only the classes you use are actually compiled into the main application (and any classes they depend on), so there's no need to worry about that.
As a last argument I also think this is a more flexible approach. A compiled library is easier to reuse and version, so the code can more easily be distributed to other developers on your team.
Rename one of the packages with right click->refactor. Than is should work.
If not you can also try to have your two codes available at the same project, and then you can select which to run in Flash Builder, by right-clicking to that .as or .mxml file, and selecting set as ... (or something like that)
I guess if you will include 'src' fonder instead of 'src/global' that problem will disappear.

Boost Library Import Into Metatrader (MT4) Script File

I am working within a Metatrader script file and need to call a function within a Boost library. Anyone know if this is possible? If so how do you configure the import?
This is possible.
Check this out: http://docs.mql4.com/basis/preprosessor/import
If you look at most metaquotes mql examples, they import stdlib and stderror . The built in help section in the editor will also have info on how to do this.
Yes, it is really possible.
But all is not as you might imagine.
Of course, it depends on what you want to do, but main idea is to create a DLL and include it to your EA as Dmitry said.
All your functions must be defined like this:
extern "C" __declspec(dllexport) int doSomething(...)
{ ... }
So you may call it from your terminal.
Be careful with c++ types in Metatrader.
In a DLL you can do what you want according to your declaration -- with all data you'll get.
Don't forgot to check your DLL for dependencies (using Dependency Walker) to see what other DLLs your library is using (you must provide them to your Metatrader terminal, copy to terminal.exe location folder, or add folder with your DLLs to your systems path).

cuPrintf cuda function

I want to use the cuPrintf function, and I get it from SDK. In the readme file they write the following
Use The cuPrintf package consists of two device functions (i.e. called
from within a CUDA kernel) and three host functions (i.e. called from
within the host application). These are packaged in a single
cuPrintf.cu file, along with declarations included in a separate
cuPrintf.cuh header file. To use cuPrintf in your application, you
must do one of the following:
a) Either: Include the header-file cuPrintf.cuh at the top of your
device code, and add cuPrintf.cu to your makefile or build
command-line so that the file is included in your program.
b) Or: Directly “#include cuPrintf.cu” at the top of your device
code. In this case you should not add this file to your
makefile/build-command, and you should take care to only include it
once in your entire project.
I tried some ways but all of them give me error, ( fatal error C1083: Cannot open include file: 'cuPrintf.cuh': No such file or directory )
I put the 'cuPrintf.cu' in the header folder in the VB 2008, and
include but give me error, and change it to
cuPrintf.cuh but also don't work.
I put both files in the extension of the project , and include them
in the code , and also give me error.
Any suggestions about how to fix it, I need this function for my code.
I solved my error , by this way :
put both files ".cu & .cuh" in the same path of the project , and include "cuPrintf.cu" in the top of the code and delete the .cu file from the header
Hope this will help who face the same error