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 ;)
Related
I'm writing a Go program that uses the GNU readline library for a fancy command line interface. In order to simplify the installing process and not worry about the library version and other stuff, I want to link it statically.
The problem is I don't really know how to do it. If I precompile the library, I would have to provide several versions of my code, with the different versions of the .a or .lib readline library. To avoid this problem I was thinking of just including the current readline code to my go project, and let the go tool compile it when it build the go project. However, to build the readline library, is necessary to use make. Is there a way of telling the go tool how to build the C code?
Yes, you can certainly do that. I've recently done something similar with a different project, mainly because the code was not available as a library (Ubuntu compiles just the command line tool for it). To achieve it, I've run the autoconf script with options that I figured would be sensible in most systems, and copied the C code together with the automatically built config.h header file into the Go package directory. Then, I've built the original C code with make once and observed which options gcc would get while compiling and linking it, and copied the appropriate ones into cgo's LDFLAGS and CFLAGS options (you can also inspect the Makefile, but that was easier).
A couple of side notes:
Have you considered doing the readline work in Go itself? The ssh terminal package works at least as a pretty good seed, if it doesn't solve your problem completely.
Remember that readline, although being a library, is GPL. You'll necessarily have to license your own software as GPL as well if you link or embed it. There are other smilar libraries available with less strict licenses, if you care.
I recommend avoiding readline, better alternatives exist; like https://github.com/edsrzf/fineline
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.
We have a software project which has the primary purpose of providing a library and API. We also provide example programs and utilities that use this library.
So, let's say that I have built and installed our library. When I run valgrind on one of the example / utility programs, I obviously see references to functions in the library. The issue is that it doesn't provide line numbers, and I would like it to.
Is there a way to tell Valgrind to reference source files that aren't obviously part of an executable, but are part of the source code for a library that is linked-in to the executable?
Thanks!
Make sure that you are compiling shared library with -g to add debug information. This should be enough for Valgrind to reference source files. See http://valgrind.org/docs/manual/faq.html#faq.unhelpful for more information.
My question may be silly, but I need to use a library from its source code without compiling it to a library form first. The tool in question is FreeType. Is this possible?
You can add all the files from the FreeType source distribution into your own project, and try to get them to compile alongside. However, the FreeType compilation procedure is a bit tricky, if I recall correctly.
It is probably easier to compile FreeType as a static library, then link your own program with the generated library. If you do that, your executable will have no dependency on the FreeType runtime library.
It's called bundling: instead of shipping your code with JAR files of some library, or even just requiring the library in your INSTALL document, you simply copy the source code into your project and have it built by your build system instead of using it pre-built. It may require adapting your build system a bit, and you need to make sure you have the right to redistribute the library in source form, but it can sometimes make sense.
MPlayer did this with ffmpeg for a long time, and XEN with the Linux kernel (notionally, they ship patches instead of the entire kernel tree). The disadvantage is, of course, that you effectively fork the library, and don't get any updates of the code whatsoever unless you re-rip their code and get it to build in your project again.
You can get the sourcecode of FreeType from http://freetype.sourceforge.net if that's what you mean.
I'm trying to migrate a project which uses Boost (particularly boost::thread and boost::asio) to VxWorks.
I can't get boost to compile using the vxworks gnu compiler. I figured that this wasn't going to be an issue as I'd seen patches on the boost trac that purport to make this possible, and since the vxworks compiler is part of the gnu tool chain I should be able to follow the directions in the boost docs for cross compilation.
I'm building on windows for a ppc vxworks.
I changed the user-config.jam file as specified in the boost docs, and used the target-os=linux option to bjam, but bjam appears to hang before it can compile. Closer inspection of the commands issued by bjam (by invoking it using the -n option) reveal that it's trying to compile with boost::thread's win32 files. This can't be right, as vxworks uses pthreads.
My bjam command: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc is set in user-config to point to the g++ppc vxworks cross compiler.
What am I doing wrong? I believe I have followed the docs to the letter.
If it's #including win32 headers instead of the pthread ones, there could be a discrepancy between the set of macros your compiler is defining and the macros the boost headers are checking for. I had a problem like that with the smart pointer headers, which in an older version of boost would check for __ppc but my compiler defined __ppc__ (or vice versa, can't remember).
touch empty.cpp
ccppc -dD -E empty.cpp
That will show you what macros are predefined by your compiler.
I never tried to compile boost for VxWorks, since I only needed a few of the headers.
Try also adding
threadapi=pthread
The documentation you mention is for Boost.Build -- which is standalone build tool -- and the above flag is something specific to Boost.Thread library. What do you mean by "hang"? Because Boost libraries are huge, it sometimes take a lot of time to scan dependencies prior to build.
If it actually hangs, can you catch bjam in a debugger and produce a backtrace? Also, log of any output will help.