I was setting up SDL in Code::Blocks 17.12, using MinGW on Windows, and I saw a weird set of options for the linker. I'm new to this, so it could be obvious. Load up a project, go into the Project tab at the top, click on Properties, then click on Project's build options. If you click on Linker settings, you'll find two things. One contains a list of libraries to link, while the other contains a list of options given to the linker in the command itself. Here's a screenshot of what the window looks like:
What I found is that removing the link libraries doesn't mess up the build at all, while removing the linker options messes up everything. Is this something that only happens with SDL? What's the difference between these two sections? What do these flags tell the linker to do?
Okay, this was a pretty simple mistake. After doing some research, I found this post on the forums explaining the problem. The libraries have to be loaded in the exact same order! To answer my first question, SDL does have some weirdness, but this problem can happen with any set of library files. Second, these two sections are basically exactly the same when it comes to linking static library files, but the linker options give you more control and let you specify other flags that the linker might use. Finally, these flags tell the linker to look into the directories provided and embed them into your program, allowing you to use the functionality present in the library in your final executable.
Here's an image showing what I did. Using the same specs as previously provided, the build ran perfectly, and I was successfully able to run the final program.
Related
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 am trying to build Quantlib using Boost Libraries.
I followed the instructions here: and also on the Quantlib website.
I downloaded and unzipped boost_1_57_0 into C:\program files
I then used the Visual Studio 2013 x64 Native prompt to go to the boost directory and ran
bootstrap.bat
and then
b2 --toolset=msvc --build-type=complete architecture=x86 address-model=64 stage
Then I opened Quantlib_vc12.sln in Visual Studio 2013.
Picked "Release" and "x64", opened "Quantlib" in Property Manager and set the VC++ Directories.
In the include directories I added C:\Programm Files\boost_1_57_0
In the Library Directories I added C:\Program Files\boost_1_57_0\stage\lib
Then I went to the Solution Explorer and right clicked and chose build.
I got one LNK1104 error.
LNK1104: cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
Please see attached screenshot:
I have no idea how to fix this and I would really appreciate some help. I had successfully installed this at work using an admin account but was not able to access Quantlib using my user account. I have since deleted and attempted installations atleast 15 times but it's not working. I am worried that all these attempts at installing may have messed something else up, like some registry (I have no idea how that works but I only know to be afraid). Please help! Thanks.
UPDATE: Still get the same error after adding BOOST_AUTO_LINK_NOMANGLE define to project.
UPDATE2: I am getting these messages on the screen while running b2 to build boost. Is this an error I need to fix?
This is exactly what I warned you about in another related question/answer. What's happening here is that the boost headers you are including in this quantlib are (through macros) detecting that you're using MSVC, detecting the version, then automatically linking the required DLL files to build quantlib using #pragma comment(lib....). So even though under Project Settings -> C/C++ -> Linker there are no external DLL's or Lib's specified, they're still being linked by these pragma statements.
So when these macros are detecting your compiler and so on, they're dynamically building a string name of what they think the required libraries would be named on your system. Remember when you built boost, you specified the -layout option. This the naming layout of your boost libraries. Well by default, that layout is something like this:
LIB_LIBRARY_NAME_COMPILER_VERSION_SingleOrMultiThreaded_BOOST_VERSION.LIB
Which in practice looks like this:
libboost_unit_test_framework-vc120-mt-1_57.lib
This is boost "mangling" the name of your library to be as descriptive as possible about how the libraries were build so that, just by glancing at the file name, you know. What we do with -layout=system is tell the boost build system NOT to mangle the names, but to name them according to what option we gave to "layout". Since we chose layout=system, boost is going to name our libraries like this:
LIB_LIBRARY_NAME.LIB
Which in practice will produce:
libboost_unit_test_framework.lib
So when we start using boost after doing this (with MSVC only does this happen), these dynamically generated linker statements don't give a rip about or know about what -layout option you built boost with. They will attempt to link in required libraries using the fully mangled naming format, which is why you get the error:
cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
.. because you don't have a file named that! That's the mangled name! You have a file named libboost_unit_test_framework.lib. See the difference! So, you need to tell these stupid macros to stop mangling the library names when auto-linking required libraries. You do that by adding the following preprocessor definition to your Quantlib project:
BOOST_AUTO_LINK_NOMANGLE
You add that in Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions.
If you'd rather avoid this headache and don't care about the long and (imo ugly) mangling that boost does to library names, you can build boost omitting the -layout option and it will default to this mangled naming convention, where you shouldn't get stuck on this error at all anymore. I personally put out the effort to keep nice short/clean library names but it's all about preference.
Edit
Since you have the same error after fixing the NO_MANGLE problem, then the only possible reason that you're getting this particular link error is that you do not have whatever file the linker is complaining about missing stored in any of the directories supplied to the linker.
Verify the folders/paths you provide to the linker and verify that the file the linker is looking for is in one of the directories that you're providing to the linker. You have to provide directories to the linker because you're telling the linker "you can look in all of these places for the libraries my project needs". If you specify none, it's got nowhere to look. :(
Example:
So I was trying to add some files to my project and double clicked on library and before I know it the whole entire library was being referenced into my project.
At first I thought, okay no big deal I'll just remove the reference, I did that it took some time, I saved afterword all seem fine, I even added some code.
From here I closed my project, come in the next day open the project and the library is in my project indexing itself. I try removing the reference again and it seems to go away, but now some of my work from the day before isn't there however some of it is, so my program can't run. To top things off Xcode crashes, open up my project again and library is still there, can someone help me with this?
From the Apple Developer Website:
http://developer.apple.com/library/ios/technotes/iOSStaticLibraries/Articles/configuration.html#//apple_ref/doc/uid/TP40012554-CH3-SW1
Select the Build Settings tab in your application target editor. Find the “Other Linker Flags” build setting. Add the flag -ObjC to this build setting’s value if it is not already present. This flag will tell the linker to link all Objective-C classes and categories from static libraries into your application, even if the linker can’t tell that they are used. This is needed because Objective-C is a dynamic language and the linker can’t always tell which classes and categories are used by your application code.
So I recommend to see if this has been done in your project settings and if it has then delete the flag in your build settings.
There is a bug in RHEL5's gcc-4.3.2 with which we are stuck. As a work-around we have extracted the missing object and put it in an object file. Adding this object file to every link makes the problem go away.
While adding it directly to LDFLAGS seems like a good solution, this doesn't work since e.g. libtool cannot cope with non-la files in there.
A slightly more portable solution seems to be to directly patch the gcc spec to add this to every link. I came up with
*startfile:
+ %{shared-libgcc:%{O*:%{!O0:/PATH/TO/ostream-inst.o}}}
where ostream-inst.o is added to the list of startfiles used in the link when compiling a shared library with optimizations.
Trying to compile boost with this spec gives some errors though since its build directly sets some objects with ld's --startgroup/--endgroup.
How should I update that spec to cover that case as well, or even better, all cases?
Go through this URL Specifying subprocesses and the switches to pass to them and GCC Command Options
If this help you, thats great.
I know this is not the answer you want to hear (since you specified otherwise in your question), but you are running into trouble here and are likely to run into more since your compiler is buggy. You should find a way of replacing it, since you'll find yourself writing even more work-around code the next time some obscure build system comes along. There's not only bjam out there.
Sorry I can't help you more. You might try simply writing a .lo file by hand (it's a two-liner, after all) and insert it into your LDFLAGS.
If it is a bug of GCC 4.3, did you try to build (by compiling from sources) and use a newer GCC. GCC 4.6.2 is coming right now. Did you consider using it?
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.