April 5, 2014 at 00:41 #1026
First of all, thank you for your impressive work with this fuzzy library. It’s much comfortable and sophisticated than matlab, even though my university provides that for free.
I’ve noticed an issue after I downloaded the package. Since you haven’t provided windows binaries for C++ development, I decided to compile it from source, but (latest) MinGW doesn’t have the dbghelp library. There are some workarounds for it as I’ve read on StackOverflow, however it was simpler just to cmake it without backtrace option and comment out these lines from the list:
lines 63-67, cmakelists:
#set(CMAKE_CXX_FLAGS ” /WX /W4 /EHsc”)
I don’t know what /WX /W4 and /EHsc are doing (probably the link above would have explained it if I had opened that :)), but CodeBlocks didn’t compile it with that line enabled.
Furthermore, since mingw-g++ haven’t found the lib using -ldbghelp flag, I also turned FL_LIBS dbghelp off.
I managed to compile it using Cmake-gui (CodeBlocks MinGW makefiles), and MinGW (4.7.1) initiated from CodeBlocks project. The sample application you posted in the C++ section also worked fine.
If I can advise, you should include a non-stripped dll so the users could make imports (using dlltool or such) for their compilers, instead of recompiling the whole package.
April 5, 2014 at 15:57 #1028
- This topic was modified 2 years, 10 months ago by bodnaar.
thank you for your post and your kind words.
It is good to see a way to make fuzzylite work under MinGW.
I like your advise of not requiring to recompile the whole package, but I do not quite follow what a non-stripped dll is. What do you mean by non-stripped dll? Would that be the file with a lib extension? Is that what you would need? Could you provide a few more details? I definitely want developers not to need to recompile the whole package, but just use the binaries provided.
Cheers.April 9, 2014 at 09:48 #1039
As far as I know, dlls can be compiled with debug/symbol information, or without it. In the first case, it is possible to create a library only from the dll file, that a compiler can use in later projects. For example mingw has its /lib subdirectory containing the libraries in order to resolve external references. These *.a files can be generated using the dll file, some grepping and a program like dlltool.
In the downloadable windows package I only found a fuzzylite.dll file that seems to be stripped. A stripped dll has no extra symbol info so *.a libraries used by mingw could not be reconstructed. The missing libfuzzylite.a file led to “unresolved reference” errors when I tried to compile my working project in CodeBlocks-MinGW.
After the compilation of the fuzzylite cmake project with mingw, I got the following binaries:
After I give this directory to mingw, it no longer reports unresolved refs. An example mingw shell command as follows:
mingw32-g++.exe -Wall -g -IC:\fuzzylite40\sources\fuzzylite -c E:\work\fuzzytest\fuzzytest.cpp -o obj\fuzzytest.o
mingw32-g++.exe -LC:\fuzzylite40\bpbuild -o bin\fuzzytest.exe obj\fuzzytest.o -lfuzzylite
…where C:\fuzzylite40\sources\fuzzylite is the include dir containing the required *.cpp headers and classes for development, and C:\fuzzylite40\bpbuild is the dir containing the binaries mentioned above. However, I guess only the libfuzzylite.dll.a is only needed in this example, and of course, the fuzzylite.dll for running the executable.
Unfortunately I don’t have much experience with dll compilation, so I can’t advise how to make a non-stripped dll with full debug info. I guess most IDEs offer it somewhere without us needing to know the command-line syntax. That would be easier if you created some /binaries subdirectory and further subdirs containing linux .so, mingw .a or visual studio libs (whatever they named in case of that).
Keep up the good work.April 9, 2014 at 10:35 #1041
Thank you very much for your feedback!
I will look into this for version 5.0.
You must be logged in to reply to this topic.