I have been trying to go through this tutorial and I always get stuck in the second build of GCC when making the cross-toolchain. It errors out saying that I am attempting to call a poisoned calloc. I have gone through several patches and what they all seem to do is just #include the offending system header (in this case pthread.h) earlier in the source code. Since there are no patches for my particular problem, I have gone ahead and emulated their solutions in my case. While this works (compilation now fails because I don't have some ISL files) it feels like a hack, and I suspect that the root problem is further back in the build.
Thus, I wanted to ask:
Why are symbols poisoned? Why would the GCC maintainers want some symbols not to be used?
What are the general causes for this problem? Is it really just a bug or is this a problem that arises in more general situations?
I am more interested in the generalities of this issue, but if it helps, I am using the latest release of Alpine Linux (with gcc 12.2.1) trying to compile gcc 11.2
.0 for the same target architecture as the host (x86-64).
Related:
How to compile srlua?
How do I Make an executable Lua script using srlua?
The first link is the exact question I am asking here. However, the sole answer is unsatisfactory as it assumes multiple things, namely that the OP is already using Cmake (a fact disproved by the OP's comment on the answer). The second link seems to already be most of the way through a tutorial, and while a link to precompiled binaries for both srlua.exe and srglue.exe are provided, the link no longer contains binaries but instead the source.
I have found several other threads on various websites all asking the same thing, but all of them either assume that you essentially already know how, or explain nothing (many have potentially helpful links, but they are old and no longer work).
I have already tried to compile srlua, and got a srglue.exe, but when I tried srlua.c I ended up with a list of undefined references (such as "lua_type" or "lua_getfield").
lua_getfield, lua_type, lua_settop, lua_getfield, lua_type, lua_settop, lua_pushstring, lua_pushinteger, lua_call, lua_pushfstring, lua_load, lua_tolstring, lua_tointeger, lua_touserdata, luaL_openlibs, lua_createtable, lua_pushstring, lua_rawseti, lua_setfield, luaL_checkstack, lua_pushstring, lua_call, lua_tolstring, luaL_callmeta, lua_type, lua_type, lua_typename, lua_pushfstring, luaL_newstate, lua_pushcclosure, lua_pushcclosure, lua_pushinteger, lua_pushlightuserdata, lua_pcall, lua_tolstring, lua_close
My question is this:
How does one use a C compiler (I know the basics of gcc) to compile srlua specifically? Or, if anyone has a functioning link to either precompiled binaries or a tool to compile the binaries, could they share it?
Important: I am on Windows. Thus, I cannot just use make. I must actually compile the .c files to .exe files. I am asking how. If you simply provide links to threads with the aforementioned problems, you are not helping. If you give an answer that assumes in-depth prior knowledge of a particular tool that does not have good documentation, you are not being helpful. If you tell me tools to use, but not the specific procedure for compiling srlua, you are not being helpful. If there is a better place for this, tell me and I can move it there.
I don't know any Windows pre-compiled binaries for srLua.
To compile srLua, you should first install the Mingw compiler to use GCC as a C compiler : you can install TDM-GCC (https://jmeubank.github.io/tdm-gcc) or http://winlibs.com.
You can then open a Console prompt. Enter the "gcc" command to be sure that the compiler is working (and that the PATH is correctly set).
Then go to the directory you extracted the srLua source files and type the command :
mingw32-make
Cross your fingers and it should compile everything :)
When linking, you should include the Lua libraries with the -l Switch : -llua54 for Lua 5.4 library for examples.
I found this already compiled release on webarchive, it's kinda old but works:
https://web.archive.org/web/20130721014948/http://www.soongsoft.com/lhf/lua/5.1/srlua.tgz
I'm using an external preprocessor (pyexpander) for my cross-platform/cross-IDE c++ project*. GCC already works nicely with the -no-integrated-cpp -B${PWD} option. I could manually preprocess each file into a specific temp dir, then compile the processed files. But is there a better way? Specifically, I'd love to hook the native preprocessors so IDE-level code analysis is happy (code completion and error checking). Any hints how I can achieve this would be much appreciated.
*"But why not use c++ macros?" They can't do macro-macros and I need that.
*"But why not use m4?" Because python happens to already be a requirement for this codebase, and m4 seems to not come with MSVS and thus would be yet another requirement/point of failure. I would still have to resolve the original preprocessor problem.
*"But why not use language something_better?" Because I have no choice in the matter. (Though I would love to use nim all the way!!)
Using gcc with -std=c++11
pkg-config libxml++-2.6 --modversion
2.40.1
get lots of warnings like this:
/usr/include/libxml++-2.6/libxml++/parsers/saxparser.h:224:8: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
I may follow the recommendation and disable this warning but I may miss other warnings in future.
I may try latest libxml++ version 2.91; despite huge minor(lol) version difference it's at most one month younger; I'll build this on older machines where libxml++ will probably be older.
I'll ignore this warning. Would anybody do otherwise ?
You should be safe ignoring the std::auto_ptr warning. Prior to C++11, auto_ptr was a common way to manage memory, because it takes ownership of a pointer. Post C++11 it's recommended to use the new smart pointers that are part of STL (ie std::unique_ptr, std::shared_ptr).
This question has a good discussion on std::auto_ptr and issues that led to it being deprecated. I wouldn't write new code using it, but existing code using auto_ptr should be safe (assuming there aren't bugs to begin with which may or may not be valid).
Well, there is a better-than-average chance that auto_ptr will be removed from C++17. So I would be at least somewhat concerned about relying on software that made use of it.
You could replace your libxml++ version by a version higher or equal than 2.9.1 They fixed the auto_ptr thing and replaced it by unique_ptr. Although you have to install libxml++-2.9.1 by hand by downloading it from:
http://ftp.gnome.org/pub/GNOME/sources/libxml++/
hope it helps.
I am having some trouble compiling a programm with gcc on windows which was initially developed with Visual Studio. So far I was able to resolve almost all problems like missing header files and such, but now I am stuck at one last thing: gcc fails to link to one of the third party libs my program uses (FlyCapture2.lib). It tells me that it does not find any of the functions/methods there. I already checked if the library is actually on the library path and that sort of things, but it still does not work.
I searched a bit around and learned that it might have something to do with the format of .libs created with the Microsoft compiler. Is there any way to convert such a lib to be compatible with gcc? Anything else I might have missed?
(I already found this similar question, but its solution won't work here)
In this page the author gives several ways to achieve what you want