Gwan include scripts - c

I am currently trying to import some libraries into my Gwan C script. I have read through the manual and am using #pragma include to include the folder that my libraries are in, and then use #pragma link to actually include the libraries, but when I run the script it error and says /usr/bin/ld: cannot find -lxxxx.a
Heres current code
#pragma include "/opt/Gwan/libraries/xxx"
#pragma link "xxxx.a"
current Gwan version 4.3.11. Thanks, any help will be appreciated
[EDIT]
All is working fine now, changed all my libraries to shared and placed them in /usr/lib

While you can link object code and static libraries with G-WAN scripts, you should rather use a dynamic library because it will only be loaded once in memory.
Do you succeed in running the (many) G-WAN examples that use third-party libraries?
(libsqlite, libcairo, libmySQL, libcURL, liboauth, libmemchached, ImageMagick, etc.)
Don't forget that you must indicate the library file name without the starting "lib" prefix (ie: sqlite3 for libsqlite3.so).
Also, libraries compiled for 64-bit won't work with G-WAN 32-bit (and vice-versa).
If this can help, there's a G-WAN FAQ dedicated on libraries which gives tips and tools to check for possible problems.
Maybe you should give the whole library names instead of the xxx in your example.

Related

Codeblocks not recognizing tcl library

I am attempting to run an old program that uses tcl as well as legacy opengl. I managed to link the opengl libraries successfully; however, I cannot seem to get the tcl linker to work. For context, the program I am using came with include and lib folder. The lib folder contains tclstub86_32.lib, tclstub86_64.lib, and tkstub86.lib as well as opengl .libs. The include folder contains two folders: tcl_include and tk_include, which obviously contain all the .c and .h files for tcl and tk. The following pictures show my settings from using project -> build options:
The error I receive when compiling is:
C:\Users\amlut\Downloads\C\tkogl\curve.c|18|undefined reference to `_imp__Tcl_Free'|
And here is the bit of code that is throwing the error:
if (*line != NULL) Tcl_Free((char*)*line);
I am not sure what I am doing wrong here, any help is appreciated. Thank you.
The problem is that the code is apparently linking against the Tcl stub library (an ABI/API adaptor library) but isn't compiling to use that library but rather to use a full Tcl library instead. When building an extension package, using the stub library is a good thing as it means that the resulting code is not bound to an exact version of the Tcl (and Tk) library but rather to a version of the Tcl ABI which has a much longer support cycle.
The fix is to define the USE_TCL_STUBS and USE_TK_STUBS (that has the identical issue; you have just hit the Tcl version of it first) C preprocessor symbols when building; set them both to 1 and recompile. This is done under the Compiler Settings tab in Code::Blocks apparently.

How to delete debug symbols in static libs

I have four libraries that I wrote in C. Now I want to share these libraries (static libs for example, libA.a) with a software developer who will use them to generate a "final" executable.
My question is, how can I delete the debug symbols so that he doesn't find some information about the working process inside my libs?
Thanks in advance.
Development Environment: GreenHills
Compiler: ccarm

How can I create and use my own static library in C?

I want to my make own library and have it use the same syntax as the standard C libraries as in
#include<mylib.h>
So that it looks like #include and some of the libraries that are included with C.
Can I make the library static as opposed to linking so that I can compile it in GCC without additional arguments, as if I were using another library like stdio.h or string.h?
This seems simple enough.
Develop the library (create as many source files as you need).
Build the source files into a shared library (.so) using a tool like CMAKE (which i strongly recommend).
Copy that library to your library path (i.e. /usr/lib)
Later on, all you have to do is import your lib: (i) in the source using #include<mylib.h>; (ii) when building (also using CMAKE) or using the flag (-lmylib) in the GCC compiler: gcc -lmylib myfiles.c -o myoutput.
In addition to #include "mylib.h", you need to add -lmylib command line to the compiler (more specifically linker) when using the library. I assume that the your library archive created through ar command is named as libmylib.a.
Usually, we do not write 'manually' build instructions, but we rely on tool that generates build chains. There are quite a lot of them, the most know are probably autotools and cmake (under Linux).
I would suggest you to have a look to cmake examples and/or documentation to get your code built.
There are quite a lot of differences between static and dynamic libs, and you will also need to package somehow your lib if you really want to use it like 'standard' lib (like libxml2, openssl, etc.)
A lot to say about it, but you should first have a look to 'how to build' your lib, and then see how to make it easy to use, IMHO.

cmake install multiple version of the same library

I am trying to have a scheme with my library that is coherent and usable/reusable.
I work in a team where we work with continuous integration but sometimes I need to use old version of the same library. That's because some part of the software are not updated for using the new version.
I'm actually in the middle of a headache understanding how to use cmake for having something like this:
PATH/Library/Processor/Library_X/Version/static_library_and_includes
Where Library is a common name where to put my stuff
Processor could be attiny24, atmega, lxpXXXX, etc
Library_X is the name of the library
Version a progressive number from 0 to X
static_library_and_includes the static libraries built within that cmake module and the include files needed for using it.
How can I do this using cmake?
I work with different microprocessor crosscompiling with gcc. This is not a problem.
I work with static library, this is not a problem.
I can install them in the right directory. Not a problem
I can't ask the executable to link to the right .a file. Sometimes cmake pick the right one, sometimes not.
Can you please give me a hint on how you guys do it?
thank in advance
Andrea
See the search paths here: https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure .
CMake will find packages in directories named name*, so you can install to <prefix>/FizzBuzz-1.0.0 and <prefix>/FizzBuzz-2.0.0.
As long as each as a correct ConfigVersion.cmake file, it should do what you want.

Problems with linking lua statically

I'm trying to link lua statically into my C++ application with VS2012. I downloaded the vs11_lib files off of sourceforge and added linker dependencies for this file, lua52.lib. I'm now getting all sorts of link errors when I try to compile and I'm pretty sure I missed a step. Again, I'm doing this statically since I'd like my application to run stand-alone. Any pointers would be greatly appreciated!
The best way is to build embeddable Lua yourself. Download source files for your desired version, create a static library project in VS2012, copy the source files (*.h and *.c to the VS project, not VS solution) and add all source files to the project, except luac.c and lua.c, which are needed for standalone executable rather than embedded library (and they conflict with each other in one project anyway).
After that compile the release version and you got yourself lua5.x.lib that you can link against. If it's still not working, then the problem might be that you added linker dependencies in the wrong place.
Lua sources can be compiled as C or C++. I figure the lib files you are trying to use are compiled as C and you are including their headers as C++. The outcome would be that the names of the functions are different; ergo, the linking errors.
If you are using a C lib in a C++ file, wrap the lib's header like so:
extern "C" {
#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
}
For more detailed instructions using Lua with Visual Studio, see this article.
UPDATE:
As, #lhf says in a comment, the newer distributions of Lua provide a C++ header lua.hpp which does the same thing. It is described for older distributions in PIL.

Resources