I am trying to compile some code for an STM32 chip using CodeBench G++ Lite tools. However, it generates an error.
startup.o: In function `LoopFillZerobss':
(.text.Reset_Handler+0x2a): undefined reference to `__libc_init_array'
I have googled and it appears that libc_init_array is probably part of some standard gcc library...but I am not sure how to fix this error?
I also have errors such as this
arm-none-eabi-ld: cannot find libc.a
and similarly for libgcc.a and libm.a
The function __libc_init_array is part of CodeSourcery's 'CS3' mechanism for 'start up' code which ensures all of a programs static initialisation happens before main is executed.
Start by ensuring all of the libraries are found. That might be enough to fix all your problems.
One approach is to use arm-none-eabi-g++, and not use arm-none-eabi-ld directly, to do the linking because g++ should correctly pass some important parameters to arm-none-eabi-ld. In some case, that might be all that is needed to find and link the correct libraries.
If you aren't sure how to build on the command line, or arm-none-eabi-g++ isn't doing everything to resolve the missing libraries, go and have a look at LeafLabs web site, where they show how build from the command line using Makefiles
http://leaflabs.com/docs/unix-toolchain.html
They provide a free, Open Source, IDE for STM32, built for Windows, Linux and Mac, which includes a working gcc-based toolchain for each of those platforms, and enough of the libraries to get started http://leaflabs.com/docs/maple-ide-install.html
Even if you'd prefer to use your toolchain for the actual build, it may be worth using theirs, with their Makefiles, to sanity check the process you are using to build your program.
I am not a member of LeafLabs staff, and have no relationship with the company other than I have bought some of their products, and try to answer questions on their forum.
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 building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
I need to link my SO against libbfd, for the purpose of having human-readable backtraces.
Static linking against libbfd.a fails, because it's not compiled with -fPIC, so as I understand, it can participate in executable only.
Though linking against libbfd.so also gives some troubles.
I need to compile on both Ubuntu-14.04 and Debian Wheezy 7.8
And they have non-intersecting sets of binutils versions. In particular, Ubuntu has 2.24, and Debian has 2.22 and 2.25. And the problem is, gcc doesn't want to take symlink's name libbfd.so to reference it, and uses SONAME instead. So i end with either libbfd-2.24-system.so or libbfd-2.25-system.so in dependencies.
For now I see several approaches:
There's some hidden flag which allows to override SONAME during linking. This is the preferred path
I have no way other than compile libbfd by hand. I would evade this as much as possible.
Manual dlopen+dlsym for everything I need.
I read answer gcc link shared library against symbolic link, but it suggests to change SONAME I'm not able to do.
Any suggestions?
Thanks.
EDIT: it seems that virtually all static libs in Ubuntu repos are not position-independent. Can't guess why. With the inability to override SONAME it makes things much more complicated.
Not sure whether i understand your (4 years old problem) correctly, but having similar problems with libbfd, I found this solution:
Using the linker flag -lbfd seems to work.
It is a linker flag that specifies g++ to link against libbfd.
My full command was g++ loader.cc -lbfd.
At least for me, errors at link-time a la "unknown function" are solved.
I'm trying to build a project (namely, Angband's source - http://rephial.org/downloads/3.3/angband-v3.3.2.tar.gz) with Emscripten's emcc in order to port it to Javascript and ultimately build an online version.
I've managed to get the process started with
emconfigure ./configure
make
which begins to successfully start generating LLVM bitcode .o files, but then it hangs up on main-gcu.c with 'main-gcu.c:43:11: fatal error: 'ncurses.h' file not found'
I believe main-gcu.c is the only file that references ncurses, but I just can't figure out how to include the library while compiling. Is there a way to specify including ncurses with 'make', or should I compile the main-gcu.c file individually, with 'emcc main-gcu.c -c -lncurses'? I tried doing that but that led to another error with emcc being unable to find other actually included header files two levels down (it couldn't find headers that were included by a header included by main-gcu.c - anyway to fix that?).
I'm also not certain if I have/need to install the ncurses library on Mac OSX. All I can really find are references to libncurses5-dev for Linux.
Thanks!
I think you misunderstand the compilation via Emscripten. I will try to point out a few problems you are facing.
The general rule is that all tools of Emscripten ONLY can turn LLVM formats (e.g. BITCODE) into JavaScript. emconfigure, emmake, ... modify the build environment so that your sourcecode is compiled to one of the LLVM formats (there are exceptions to the rule but nevermind). So anything you want to link against your final result has to be in a LLVM format, as well (which by default ncurses is not).
Since the output is JavaScript, there is no chance to execute any program code in different threads. While a lot of C/C++ code does use a thread for the UI and others for processing, such a model does NOT work for Emscripten. So in order to get the software compiling/running you will have to rewrite the parts that use threading. See emscripten_set_main_loop for pointers.
Even if you have the libraries compiled you then have to statically link them to Emscripten. At this point it is less of a technical problem but more of a license issue since if your library is licensed under e.g. LGPL due to static linking the GPL terms are effective.
I hope all clarity finally vanished ;)
I'm trying to port some very old fortran code to windows. I'd like to use mingw and f2c, which has no problem converting the code to usable C on OS X and Ubuntu. I used f2c.exe as distributed by netlib on a fresh install of mingw, and it translated the code fine. I have a "ported" version of libf2c that seems to still contain some unresolved references -- mostly file i/o routines (do_fio, f_open, s_wsfe, e_wsfe) and, peculiarly, one arithmetic routine (pow_dd). To resolve these issues, I tried to build libf2c from source, but ran into an issue during the make process. The make proceeds to dtime_.c, but then fails due to a dependency on sys/times.h, which is no longer a part of the mingw distro. There appears to be a struct defined in times.h that defines the size of a variable in dtime_.c, specifically t and t0 on lines 53 and 54 (error is "storage size of 't' isn't known"; same for t0).
The makefile was modified to use gcc, and make invoked with no other options passed.
Might anyone know of a workaround for this issue? I feel confident that once I have a properly compiled libf2c, I'll be able to link it with gcc and the code will work like it does on linux and os X.
FOLLOW-UP: I was able to build libf2c.a by commenting out the time related files in the makefile (my code does not contain any time related functions, so don't think it will matter). I copied it to a non-POSIX search directory as show in -print-search-dirs, specifically C:\MinGW\lib\gcc\mingw32\3.4.5. That seems to have fixed the issue on the unresolved references, although the need to eliminate the time files does concern me. While my code is now working, the original question stands -- how to handle makefiles that call for sys/times.h in mingw?
Are you sure the MinGW installation went correct? As far as I can tell the sys/times.h header is still there, in the package mingwrt-3.18-mingw32-dev.tar.gz. I'm not familiar with the gui installer, but perhaps you have to tick a box for the mingwrt dev component.