I know how to use patsopt and atscc2js to compile ATS code into JS code:
patsopt -d foo.dats | atscc2js -o foo_dats.js
Do I need to include some kind of JS library for atscc2js in order to run the JS code in foo_dats.js?
Yes, you will need to include at least libatscc2js_all.js.
Related
I'm experimenting a bit with building DLLs on windows using MINGW.
A very good summary (in my opinion) can be found at:
https://www.transmissionzero.co.uk/computing/building-dlls-with-mingw/
There is even a basic project which can be used for the purpose of this discussion:
https://github.com/TransmissionZero/MinGW-DLL-Example/releases/tag/rel%2Fv1.1
Note there is a cosmetic mistake in this project which will make it fail out of the box: the Makefile does not create an "obj" directory - Either adjust the Makefile or create it manually.
So here is the real question.
How to change the Windows DLL name so it differs from the actual DLL file name ??
Essentially I'm trying to achieve on Windows, the effect which is very well described here on Linux:
https://www.man7.org/conf/lca2006/shared_libraries/slide4b.html
Initially I tried changing "InternalName" and ""OriginalFilename" in the resource file used to create the DLL but that does not work.
In a second step, I tried adding "-Wl,-soname,SoName.dll" on the command that performs the final link, to change the Windows DLL name.
However, that does not seem to have the expected effect (I'm using MingW 7.3.0, x86_64-posix-seh-rev0).
Two things makes me say that:
1/ The test executable still works (I would expect it to fail, because it tries to locate SoName.dll but can't find it).
2/ "pexports.exe AddLib.dll" produces the output below, where the library name hasn't changed:
LIBRARY "AddLib.dll"
EXPORTS
Add
bar DATA
foo DATA
Am I doing anything wrong ? Are my expectations wrong perhaps ?
Thanks for your help !
David
First of all, I would like to say it's important to use either a .def file for specifying the exported symbols or use __declspec(dllexport) / __declspec(dllimport), but never mix these two methods. There is also another method using the -Wl,--export-all-symbols linker flag, but I think that's ugly and should only be used when quick and dirty is what you want.
It is possible to tell MinGW to use a DLL filename that does not match the library name. In the link step use -o to specify the DLL and use -Wl,--out-implib, to specify the library file.
Let me illustrate by showing how to build chebyshev as a both static and shared library. Its sources consist of only only 2 files: chebyshev.h and chebyshev.c.
Compile
gcc -c -o chebyshev.o chebyshev.c -I. -O3
Create static library
ar cr libchebyshev.a chebyshev.o
Create a .def file (as it wasn't supplied and __declspec(dllexport) / __declspec(dllimport) wasn't used either). Note that this file doesn't contain a line with LIBRARY allowing the linker to specify the DLL filename later.
There are several ways to do this if the .def file wasn't supplied by the project:
3.1. Get the symbols from the .h file(s). This may be hard as sometimes you need to distinguish for example between type definitions (like typedef, enum, struct) and actual functions and variables that need to be exported;
echo "EXPORTS" > chebyshev.def
sed -n -e "s/^.* \**\(chebyshev_.*\) *(.*$/\1/p" chebyshev.h >> chebyshev.def
3.2. Use nm to list symbols in the library file and filter out the type of symbols you need.
echo "EXPORTS" > chebyshev.def
nm -f posix --defined-only -p libchebyshev.a | sed -n -e "s/^_*\([^ ]*\) T .*$/\1/p" >> chebyshev.def
Link the static library into the shared library.
gcc -shared -s -mwindows -def chebyshev.def -o chebyshev-0.dll -Wl,--out-implib,libchebyshev.dll.a libchebyshev.a
If you have a project that uses __declspec(dllexport) / __declspec(dllimport) things are a lot easier. And you can even have the link step generate a .def file using the -Wl,--output-def, linker flag like this:
gcc -shared -s -mwindows -o myproject.dll -Wl,--out-implib,myproject.dll.a -Wl,--output-def,myproject.def myproject.o
This answer is based on my experiences with C. For C++ you really should use __declspec(dllexport) / __declspec(dllimport).
I believe I have found one mechanism to achieve on Windows, the effect described for Linux in https://www.man7.org/conf/lca2006/shared_libraries/slide4b.html
This involves dll_tool
In the example Makefile there was originally this line:
gcc -o AddLib.dll obj/add.o obj/resource.o -shared -s -Wl,--subsystem,windows,--out-implib,libaddlib.a
I simply replaced it with the 2 lines below instead:
dlltool -e obj/exports.o --dllname soname.dll -l libAddLib.a obj/resource.o obj/add.o
gcc -o AddLib.dll obj/resource.o obj/add.o obj/exports.o -shared -s -Wl,--subsystem,windows
Really, the key seems to be the creation with dlltool of an exports file in conjunction with dllname. This exports file is linked with the object files that make up the body of the DLL and it handles the interface between the DLL and the outside world. Note that dlltool also creates the "import library" at the same time
Now I get the expected effect, and I can see that the "Internal DLL name" (not sure what the correct terminology is) has changed:
First evidence:
>> dlltool.exe -I libAddLib.a
soname.dll
Second evidence:
>> pexports.exe AddLib.dll
LIBRARY "soname.dll"
EXPORTS
Add
bar DATA
foo DATA
Third evidence:
>> AddTest.exe
Error: the code execution cannot proceed because soname.dll was not found.
Although the desired effect is achieved, this still seems to be some sort of workaround. My understanding (but I could well be wrong) is that the gcc option "-Wl,-soname" should achieve exactly the same thing. At least it does on Linux, but is this broken on Windows perhaps ??
I build my own static library with gcc and ar like this.
g++ \
... list of library sources ... \
... a lot of -L -l -I -D options etc... \
-c \
&& ar crf ./lib/libpackager.a *.o
Then I use this library in my app. Currently I built it like this.
g++ \
myApp.cpp \
... same -L -l -I options as in library ... \
-L. -lpackager \
-o myApp
It works, but I am little odd for me that I need to duplicate all -l and -L during building the app. Is it possible include all this library dependencies inside the library. My goal to build app like this.
g++ myApp.cpp -L. -lpackager -o myApp
Transferring comments into an answer.
Specifying the -l and -L operations when compiling to object files is irrelevant. Some versions of GCC warn about arguments that won't be used because they are link-time arguments, and linking won't be used when you include the -c flag.
The ar command doesn't know what to do with the C compiler's -l and -L arguments (it might have its own uses for the flags; one version of ar accepts but ignores -l).
So, you have to specify the dependencies when you link with the static library. That is the way life has been since the early 70s — that aspect hasn't changed yet.
Shared libraries can be built with the dependency information, but not static libraries.
As I understand it, I need to build a shared library and link it in a static way, right?
No. You either need to build and link a shared library as a shared library, or you need to accept that using a static library means you will need to specify other libraries on the command line when you use this library. There are systems to help manage such information; pkg-config is one such. AFAIK, you cannot link a shared library in a 'static way'.
I'm having problems creating a lib and using it to link a .c-file with a main-function.
I have e.g.
cfile1.c
cfile2.c
cfile3.c
program.c (with main-function)
I want to create a library from all the .c-files and use it to link the
program.c
What is the best way to do that?
I assume your program.c (which is main) need those *.c files(support) to make a new library. If is that so, may be you should compile all of them because your program.c need that (if there is a function on *.c files called on program.c files)
I think, you can take a look on this link below:
Including one C source file in another?
Hope it helps, CMIIW
I have a problem on linking static libraries..
I have checked and proceeded some methods to solve it, like.. reordering libraries or using some options..
However, All what I've done didn't work..
--
First of all, I'm quite sure it is from link error because I have checked the .a file by nm command and there was specific functions shown in error log.
So, I linked static library like below..
LOCAL_LINK_STATIC_LIBS := \
-I$(libdir)/libmicrohttpd.a\
-I$(libdir)/libcryptopp.a\
...
myprog_LDFLAGS = -lstdc++ -g -ldl -lpthread #GLIB_CFLAGS# $(LOCAL_LINK_STATIC_LIBS)
Is there other way to solve it? I really need your feedback..
Thanks for reading.
You must only supply the name with the -l option, e.g. -lmicrohttpd. The linker will add "lib" and ".a" or ".so". Use the -L option to set the search path for the libraries, e.g. -L$(libdir).
Also try using -pthread instead of -lpthread. -lpthread only links the pthread library whereas -pthread will do some additional work.
I'm building ubuntu-8.04 with gcc 3.4 and I need to generate the .i files, which are the output of the gcc preprocessor. I have tried adding the --save-temps flag but this only generates the .i files for the top level directory, i.e. source, and does not seem to get passed recursively to the child directories. I also tried the -E flag, which is supposed to output preprocessed files and stop compilation, but this did not generate the files either.
I'm specifically looking to generate the .i files for the source in net/core.
Any help is appreciated. Thanks!!
There is no support for bulk preprocessing.
For single file use "make net/core/foo.i"
For bulk, workaround is "make C=2 CHECK="cc -E"".
I know that is an old post, but maybe can be useful; for me this works:
gcc -E filename.c -o outputfile.i