CODEWITHSUNDEEP
includeg++pragmag-wan
Gabe Rainbow
Gabe Rainbow

Reputation: 3738

g-wan: building library outside of /csp, and g++ compilation problems

I am giving Gwan a whirl.

Having made it through example code, I started a small project with more than one source file. I now have two problems:

  1. I got a linking error at server startup:

    Linking main.cpp: undefined symbol: _ZN7GwanUrl9concatAllEv

(the main file #includes the two other files; all the files are in the csp directory)

  1. As an alternative to having all the files in the /csp directory, I would like to make a library outside of the /csp directory while still using some of the gwan functions. sadly, a tonne of errors follow -- WHEN I GCC from commandline not via G-WAN Startup.

    In file included from /home/ec2-user/gwan/include/gwan.h:22, from Xbufstream.h:10, from Xbufstream.cpp:10: /usr/include/time.h:199: error: ‘size_t’ does not name a type .....

Anyone knows what the gwan g++ argument string looks like?

(odd the 1. and 1. its 1. and 2. in the editor)

Upvotes: 1

Views: 347

Answers (2)

Gabe Rainbow
Gabe Rainbow

Reputation: 3738

the issue of referencing gwan.h symbols inside #include files can also be solved by moving all code into the header file, whether its .h or .hpp

its ungraceful but a fix nevertheless. and good enough for the simple extension i wanted.

looking into the /libraries/sqlite3/sqlite.h helped.

@gil, thanks for your time.

Upvotes: 0

Gil
Gil

Reputation: 3334

First, this is not a linker issue: you have "undefined symbol" rather than "unresolved symbol" as an error.

This is simply an #include issue.

  1. define the main() function in your script.cpp file.

  2. there's a G-WAN folder dedicated to user-defined include files called /gwan/include but you can as well use /csp/my_include.hpp... if you are using the right syntax:

For example, having #include "toto.hpp" in /csp/hello.cpp lets me reach C++ functions defined and implemented in the gwan/include/toto.hpp file (or defined in toto.hpp and implemented in a pre-compiled library linked to your script with #pragma link).

If you rather use #include <toto.hpp> then the SYSTEM INCLUDE PATH will be searched instead (and this will work providing that your library was correctly installed).

If you want to use #include "toto.hpp" for a custom folder that was not setup in the system, you can use G-WAN's #pragma include "../my_folder" directive to specify its PATH or you can explicitely specify it in each include: #include "../my_folder/toto.hpp".

Nothing fancy there, only C/C++ dependancy rules apply (and G-WAN really helps by providing alternate ways that do not involve system settings).

For libraries (see the G-WAN examples for SQLite, Cairo, mySQL, cURL, etc.) you can either use pre-installed libraries that exported their location in SYSTEM variables... or put your library in the /gwan/libraries folder and their include file in the /gwan/include folder.

When writing your own libraries, remember that they need to be pre-compiled. This means that you obviously cannot use G-WAN symbols since your compiler may #include "gwan.h" (to have the definitions) but your linker will not know from where G-WAN symbols can be found. The way around is to always use the G-WAN API from the G-WAN scripts. Your custom libraries must either be general-purpose or buffer any payload intended to be used by G-WAN. No-double copy is needed since G-WAN provides the set_reply() call to let G-WAN use persistent replies built without the reply xbuffer provided by G-WAN servlets.

Now, a last word about linking (which was not the cause of your trouble but could participate to the confusion). If you mix C and C++, use extern C {} to wrap your C++ prototypes called from C (otherwise you will really have "unresolved symbols").

With all this information, you should be ready to face every possible situation.

Upvotes: 1

Related Questions