I am trying to static link lua into a FreePascal application. I have fixed all of the errors during the linking except this one.
Undefined Symbol: __strtod
All of the other Undefined Symbols I was able to link in via libkernel32.a, libuser32.a and libmsvcr.a from the MinGW compiler which I used to compile the liblualib.a that I am linking in in place of using the dll.
I would like to have this static linked and not dynamic linked. So, would anyone happen to know which .a lib file ___strtod is defined in or know how I can search and find this out.
To my knowledge it is a C99 function and MinGW, GCC support it. So, I would think that it would be in one of the lib (.a) files that come with it.
Thanks,
Turns out that I never came back and answered my question when I got it to work.
I searched online for the function in C and then compiled it to a static library using MinGW. With the libstrtod.a file that I created I was able to static link it into the program compiled by FreePascal.
I have since had to give up the source for this project since it was on contract, I will try to remember to make an example of this to share.
Thanks for all of the responses and suggestions.
to be continued...
It's part of the C library, libc. However I don't know you can statically link to it. (Are there yet systems which provide static versions of libc?)
Libc should be linked by default in a C program.
Just create a make file that uses a static version of the library.
The static libraries are normally much bigger than the dynamic ones.
You could download newlib and compile the source directly with the lua runtime,
I'm guessing that newlib works with MinGW.
I hope this helps.
Related
I'm trying to run a program in Code::Blocks, and in my program I have used the hash functions, such as hsearch and hcreate, but Code::Blocks seems to not allow them.
I have the header:
#include <search.h>
included already, but errors such as "undefined reference to 'hsearch' " still comes up.
Is there anyway to allow these functions to run in Code::Blocks at all?
Header files are just containing the declarations. You need to have the libraries installed, which are containing the implementation.
And that what it is telling you. It found the declarations just fine, however the linker did not find the libraries, hence the linkage error.
On Linux, the search.h and its implementation is part of the libc, so it is already ready to use. On Windows, however, you need to get a binary version of it, set up the library path for Code::Blocks, and use the linker options in the settings.
The teacher asked to do the two tasks given in the title,and the only hint he gave is that the library file will have extension ".lib" . I have tried to make a static library using Code Blocks, and it has ".a" extension instead of .lib. Now how do I call and use this library in MASM, I have no idea. Please Help!
A .a file is a static library on Linux / UNIX. Code Blocks is cross-platform, but often found on Linux, so I wouldn't be surprised if you were running it there.
A .lib file is a static library on Windows. MASM is the Microsoft (Windows) assembler.
You're not using the right toolchain for your platform. Or potentially, you're not even working on the right platform.
I am developing a bare metal C applications on an ST ARM-Cortex-M3. I have also developed libraries that are usable across all these applications.
I used to use Keil ARM-MDK, but want to move over to GNU-GCC. I thus downloaded the latest version of GCC and started recompiling the code.
Although similar questions to this one have been answered, it does not solve my problem ans therefore I am posting my question.
I have a problem with the following:
Lib_Flash has a function Read_Flash(). Lib_AppCfg links in Lib_Flash as it uses Read_Flash().
My application (App) links in both Lib_Flash and Lib_AppCfg. App also uses Read_Flash() for some specific FLASH checks.
In Keil MDK-ARM it worked fine.
With GCC, when functions using Lib_AppCfg are built, I get errors stating that Read_Flash() is an "undefined reference".
I am not sure where the problem lies. Is it in the linking of the Lib_Appcfg is built or is the problem when I link App?
Please advise. If you need additional information, please let me know.
The GNU linker by default searches the libraries once in the order listed on the command line. So if a library later in the list has a reference to symbol defined in an earlier library or object file, then it cannot be resolved.
The simple solution is to use library grouping; this causes the linker to repeatedly search a list of libraries until no further synbols can be resolved. If you are invoking the linker (ld) separately, then the linker options are:
--start-group _Flash _AppCfg --end-group
or the alternative form
-( _Flash _AppCfg -)
See the GNU linker manual for details. If driving the linker indirectly through gcc you pass linker options via the -Wl option, something like:
-Wl,-(,_Flash,_AppCfg,-)
I think.
It sounds to me like you have got an ordering problem in your libraries. Some linkers will rescan all the libraries on the command line till all references are resolved (or can't be resolved). Other linkers work sequentially along the link line.
In particular, this means that if library A defines a symbol SYM_A and library B which comes after library A references this symbol, it won't be resolved on the 2nd type of linker, and your link will fail.
To get round this, you can do one or more of the following
Reorder the libraries
Replicate libraries on the link line where
necessary
Refactor your libraries so there aren't mutual
dependencies between them (that is A references symbol SYMB, which
is defined in B, but B references SYMA)
My executable needs zlib1.dll to run,
and I need to keep them together now and then.
How can I merge it into the executable to save the trouble?
I'm using cmake to build the executable.
UPDATE
zlib1.dll is not directly included by my programe,but required by libpng14-14.dll(one dll of the gtk bundle)
It sounds like you want to link statically so that your program does not require the presence of zlib1.dll in order to run. But zlib1.dll is a dynamic link library (that's what DLL stands for!), so you can't link it statically. The first thing you need to do is find a static version of this library. On windows, it will normally end with the .lib extension.
I'm not familiar with cmake, so I'll let someone else answer the part of the question about how to make cmake use the static library, once you have both.
Sorry there is no way to mix it. Either you must compile and link statically or dynamically. I tried it - it does not work.
So if libpng.dll needs a zlib.dll you can't turn zlib into a static library. You have to also compile libpng as a static library.
I've done this a few times, the makefiles from PNG, ZLIB, (and also the JPEG, TIFF image format libraries) are pretty good. If you need more then 30min to figure out what to do, you should look at it as a good training on your C makefile skills.
I compiled libxml2 with BCC 5.5 command line compiler, now I have lots of .obj files which I'd like to link into my Delphi application. Unfortunately, I get lots of "Unsatisfied forward or external declaration" errors, pointing to standard C library functions like memcpy, open, recv etc ...
What should I do to compile it correctly? I'd like to avoid depending on msvcrt.dll or any other external libraries.
Thanks in advance!
Depending on the version of Delphi you have, there should be a unit called crtl.dcu with which you can link. Just use the $L directive for each .obj file in a unit that also uses crtl. You may also need to "use" other various units like Windows, WinSock, etc... The point is to provide the symbols and functions to resolve during the link phase.
This is the same technique used to statically link in the DataSnap TClientDataSet code used to also build midas.dll.
you should read article of Rudy here "Using C object files in Delphi"
Don't use those functions, but rewrite them to call operating system functions (kernel32/system32) directly.