Issue compiling hello world on Wt - wt

I try to compile a hello world like application using Wt but have problems to link
I use Qt creator and mingw32 as compiler
what am I doing wrong ? Any help will be appreciated
The process "C:/MinGW32/bin/mingw32-make.exe" exited normally.
Configuration unchanged, skipping qmake step.
Starting: "C:/MinGW32/bin/mingw32-make.exe" -w
mingw32-make: Entering directory `C:/Wt/HelloWt-build-desktop'
C:/MinGW32/bin/mingw32-make -f Makefile.Debug
mingw32-make[1]: Entering directory `C:/Wt/HelloWt-build-desktop'
g++ -c -DNDEBUG -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -D__MINGW32__ -D_WIN32 -DQT_DLL -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I'../../Qt/2010.05/qt/include/QtCore' -I'../../Qt/2010.05/qt/include/QtNetwork' -I'../../Qt/2010.05/qt/include' -I'../../Wt2/Include' -I'../../boost/include/boost-1_45' -I'../../Qt/2010.05/qt/include/ActiveQt' -I'debug' -I'../../WtTest/HelloWt' -I'.' -I'../../Qt/2010.05/qt/mkspecs/win32-g++' -o debug/main.o ../../WtTest/HelloWt/main.cpp
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o debug/HelloWt.exe debug/main.o -L'c:/Qt/2010.05/qt/lib' C:\Wt2\lib\libwt.a C:\Wt2\lib\libwthttp.a C:\QtSDK\mingw\lib\libws2_32.a C:\QtSDK\mingw\lib\libwsock32.a C:\boost\lib\libboost_thread-mgw45-mt-d-1_45.a C:\boost\lib\libboost_regex-mgw45-mt-d-1_45.a C:\boost\lib\libboost_date_time-mgw45-mt-d-1_45.a C:\boost\lib\libboost_signals-mgw45-mt-d-1_45.a C:\boost\lib\libboost_system-mgw45-mt-d-1_45.a C:\boost\lib\libboost_program_options-mgw45-mt-d-1_45.a C:\boost\lib\libboost_filesystem-mgw45-mt-d-1_45.a -lQtNetworkd4 -lQtCored4
mingw32-make[1]: Leaving directory `C:/Wt/HelloWt-build-desktop'
mingw32-make: Leaving directory `C:/Wt/HelloWt-build-desktop'
C:\Wt2\lib\libwthttp.a(WServer.obj): In function `WServer':
C:/wt-3.1.9/src/http/WServer.C:142: undefined reference to `Wt::WAbstractServer::instance_'
C:/wt-3.1.9/src/http/WServer.C:140: undefined reference to `Wt::WAbstractServer::~WAbstractServer()'
C:\Wt2\lib\libwthttp.a(WServer.obj): In function `~HTTPStream':
C:/wt-3.1.9/src/http/HTTPStream.h:16: undefined reference to `Wt::WebStream::~WebStream()'
C:\Wt2\lib\libwthttp.a(WServer.obj): In function `~WServer':
C:/wt-3.1.9/src/http/WServer.C:145: undefined reference to `Wt::WAbstractServer::~WAbstractServer()'
C:\Wt2\lib\libwthttp.a(WServer.obj): In function `~HTTPStream':
C:/wt-3.1.9/src/http/HTTPStream.h:16: undefined reference to `Wt::WebStream::~WebStream()'
C:\Wt2\lib\libwthttp.a(WServer.obj): In function `~WServer':
C:/wt-3.1.9/src/http/WServer.C:145: undefined reference to `Wt::WAbstractServer::~WAbstractServer()'
C:\Wt2\lib\libwthttp.a(HTTPStream.obj): In function `HTTPStream':
C:/wt-3.1.9/src/http/HTTPStream.C:17: undefined reference to `Wt::WebStream::WebStream(bool)'
C:\Wt2\lib\libwthttp.a(HTTPStream.obj): In function `~HTTPStream':
C:/wt-3.1.9/src/http/HTTPStream.h:16: undefined reference to `Wt::WebStream::~WebStream()'
C:/wt-3.1.9/src/http/HTTPStream.h:16: undefined reference to `Wt::WebStream::~WebStream()'
collect2: ld returned 1 exit status
mingw32-make[1]: *** [debug/HelloWt.exe] Error 1
mingw32-make: *** [debug] Error 2
The process "C:/MinGW32/bin/mingw32-make.exe" exited with code %2.
Error while building project HelloWt (target: Desktop)
When executing build step 'Make'
Here is the source
#include <Wt/WApplication>
#include <Wt/WBreak>
#include <Wt/WContainerWidget>
#include <Wt/WLineEdit>
#include <Wt/WPushButton>
#include <Wt/WText>
#include <boost/version.hpp>
using namespace Wt;
/*
* A simple hello world application class which demonstrates how to react
* to events, read input, and give feed-back.
*/
class HelloApplication : public WApplication
{
public:
HelloApplication(const WEnvironment& env);
private:
WLineEdit *nameEdit_;
WText *greeting_;
void greet();
};
/*
* The env argument contains information about the new session, and
* the initial request. It must be passed to the WApplication
* constructor so it is typically also an argument for your custom
* application constructor.
*/
HelloApplication::HelloApplication(const WEnvironment& env)
: WApplication(env)
{
setTitle("Hello world"); // application title
root()->addWidget(new WText("Your name, please ? ")); // show some text
nameEdit_ = new WLineEdit(root()); // allow text input
nameEdit_->setFocus(); // give focus
WPushButton *b = new WPushButton("Greet me.", root()); // create a button
b->setMargin(5, Left); // add 5 pixels margin
root()->addWidget(new WBreak()); // insert a line break
greeting_ = new WText(root()); // empty text
/*
* Connect signals with slots
*
* - simple Wt-way
*/
b->clicked().connect(this, &HelloApplication::greet);
/*
* - using an arbitrary function object (binding values with boost::bind())
*/
nameEdit_->enterPressed().connect
(boost::bind(&HelloApplication::greet, this));
}
void HelloApplication::greet()
{
/*
* Update the text, using text input into the nameEdit_ field.
*/
greeting_->setText("Hello there, " + nameEdit_->text());
}
WApplication *createApplication(const WEnvironment& env)
{
/*
* You could read information from the environment to decide whether
* the user has permission to start a new application
*/
return new HelloApplication(env);
}
int main(int argc, char **argv)
{
/*
* Your main method may set up some shared resources, but should then
* start the server application (FastCGI or httpd) that starts listening
* for requests, and handles all of the application life cycles.
*
* The last argument to WRun specifies the function that will instantiate
* new application objects. That function is executed when a new user surfs
* to the Wt application, and after the library has negotiated browser
* support. The function should return a newly instantiated application
* object.
*/
return WRun(argc, argv, &createApplication);
}

You may need to reverse the order of libwt.a and libwthttp.a on your command line. The order of arguments sometimes matters to the GNU linker.

You are trying to link you application with QtCore, QtNetwork and ActiveQt libraries, and not with Wt libraries.
As far as I can see you are unsing qmake and then make.
If you do, check you project configuration file, and compare with Hello World example of Wt used with qmake:
QT -= core
QT -= gui
TARGET = CppHelloWtQtCreatorUbuntu
LIBS += -L/usr/lib -lwt -lwthttp
QMAKE_CXXFLAGS += -DNDEBUG
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += main.cpp \
wittyapplication.cpp
HEADERS += \
wittyapplication.h
As you can see here, all linking with Qt libraries are removed and added wt and wthttp (to have binary witch is a standalone webserver) libs.
Also make shure you have Wt header files accesible via INCLUDE enviroment variable and Wt libraries are acessibe via PATH enviroment variable.

Related

Compilation and linking issues on MacOS for canonical/libco - "Undefined symbols for architecture"

I'm on MacOS Catalina 10.15.3. I'm trying to build Caonical's dqlite as I want to try the experimental features of k3s which uses it as distributed database instead of etcd or others.
The error I'm seeing is with one of the dependencies, libco.
I built the library with the following commands:
clang libco.c -g -O2 -Wall -fPIC -c -DLIBCO_MP
clang libco.o -dynamiclib -Wl,-install_name,libco.dylib -o libco.dylib
and I have moved these files to /usr/local/lib/libco.dylib and /usr/local/include/libco.h respectively.
The issue is raised when I try to build a simple test file (please ignore errors in this file, I tried adapting this one as stand-alone test):
#include <libco.h>
#include <stdlib.h>
#include <assert.h>
/* Execution context of a test coroutine, passed using the global ctx
* variable. */
struct ctx
{
cothread_t main; /* Reference to the main coroutine */
int v1;
int v2;
};
static struct ctx *ctx; /* Argument for test coroutines */
struct fixture
{
cothread_t main; /* Main coroutine */
cothread_t coro1; /* First coroutine */
cothread_t coro2; /* Second coroutine */
struct ctx ctx1; /* Context for first coroutine */
struct ctx ctx2; /* Context for second coroutine */
};
static void coro()
{
struct ctx *c = ctx;
c->v1 = 1;
co_switch(c->main);
c->v2 = 2;
co_switch(c->main);
}
int main()
{
struct fixture *f = malloc(sizeof *f);
f->main = co_active();
f->coro1 = co_create(1024 * 1024, coro);
f->coro2 = co_create(1024 * 1024, coro);
f->ctx1.main = f->main;
f->ctx2.main = f->main;
/* Start executing coro1 */
ctx = &f->ctx1;
co_switch(f->coro1);
/* The v1 field of the context has been initialized, but v2 has not. */
assert(f->ctx1.v1 == 1);
assert(f->ctx1.v2 == 0);
/* Start executing coro2 */
ctx = &f->ctx2;
co_switch(f->coro2);
/* The v1 field of the second context has been initialized, but v2 has
* not. */
assert(f->ctx2.v1 == 1);
assert(f->ctx2.v2 == 0);
/* The fields of the first context are still the same. */
assert(f->ctx1.v1 == 1);
assert(f->ctx1.v2 == 0);
/* Resume execution of coro2 */
co_switch(f->coro2);
/* The v2 field of the second context has been initialized too, but the
* one of the first context still hasn't. */
assert(f->ctx2.v1 == 1);
assert(f->ctx2.v2 == 2);
assert(f->ctx1.v1 == 1);
assert(f->ctx1.v2 == 0);
/* Resume execution of coro1 */
co_switch(f->coro1);
/* The v2 field of the first context has been initialized too now. */
assert(f->ctx1.v1 == 1);
assert(f->ctx1.v2 == 2);
co_delete(f->coro1);
co_delete(f->coro2);
free(f);
return 0;
}
Trying to compile using clang test.c -o test results in the following:
Undefined symbols for architecture x86_64:
"_co_active", referenced from:
_main in test-b98908.o
"_co_create", referenced from:
_main in test-b98908.o
"_co_delete", referenced from:
_main in test-b98908.o
"_co_switch", referenced from:
_main in test-b98908.o
_coro in test-b98908.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Upon further inspection, however, I find that those symbols seem to be defined in the libco.dylib library:
$ lipo -info /usr/local/lib/libco.dylib
Non-fat file: /usr/local/lib/libco.dylib is architecture: x86_64
$ nm /usr/local/lib/libco.dylib
U ___assert_rtn
0000000000005058 d __dyld_private
U __tlv_bootstrap
0000000000001d60 T _co_active
0000000000005040 s _co_active_buffer
0000000000005070 s _co_active_buffer$tlv$init
0000000000005028 s _co_active_handle
0000000000005060 s _co_active_handle$tlv$init
0000000000001e60 T _co_create
0000000000001f20 T _co_delete
0000000000001da0 T _co_derive
0000000000001f50 T _co_serializable
0000000000005270 b _co_swap
0000000000002000 s _co_swap_function
0000000000001f30 T _co_switch
0000000000001f60 t _crash
0000000000001f70 t _crash.cold.1
U _free
U _malloc
U _mprotect
U _sysconf
U dyld_stub_binder
I guess the only option remaining is that the compiler isn't finding the library, so the issue could be a name or library path resolution issue but I can't seem to figure it out.
What am I missing?
Thank you.
You need to tell clang where the include files are, which directory the libraries are in and which libraries you want to use:
clang program.c -o program -I/usr/local/include -L/usr/local/lib -lco

Weird C library linkage issues on Mac - Segmentation Fault

I have a strange segmentation fault that doesn't exist when everything is in 1 .c file, but does exist when I put part of the code in a dynamically linked library and link it to a test file. The complete code for the working 1 .c file code is at the bottom, the complete code for the error system with 2 .c and 1 .h file come first.
Here is the error system:
example.h:
#include <stdio.h>
#include <stdlib.h>
typedef struct MYARRAY {
int len;
void* items[];
} MYARRAY;
MYARRAY *collection;
void
mypush(void* p);
example.c:
#include "example.h"
void
mypush(void* p) {
printf("Here %lu\n", sizeof collection);
puts("FOO");
int len = collection->len++;
puts("BAR");
collection->items[len] = p;
}
example2.c:
This is essentially a test file:
#include "example.h"
void
test_print() {
puts("Here1");
mypush("foo");
puts("Here2");
}
int
main() {
collection = malloc(sizeof *collection + (sizeof collection->items[0] * 1000));
collection->len = 0;
puts("Start");
test_print();
puts("Done");
return 0;
}
Makefile:
I link example to example2 here, and run:
example:
#clang -I . -dynamiclib \
-undefined dynamic_lookup \
-o example.dylib example.c
#clang example2.c example.dylib -o example2.o
#./example2.o
.PHONY: example
The output is:
$ make example
Start
Here1
Here 8
FOO
make: *** [example] Segmentation fault: 11
But it should show the full output of:
$ make example
Start
Here1
Here 8
FOO
BAR
Here2
Done
The weird thing is everything works if it is this system:
example.c:
#include <stdio.h>
#include <stdlib.h>
typedef struct MYARRAY {
int len;
void* items[];
} MYARRAY;
MYARRAY *collection;
void
mypush(void* p) {
printf("Here %lu\n", sizeof collection);
puts("FOO");
int len = collection->len++;
puts("BAR");
collection->items[len] = p;
}
void
test_print() {
puts("Here1");
mypush("foo");
puts("Here");
}
int
main() {
collection = malloc(sizeof *collection + (sizeof collection->items[0] * 1000));
collection->len = 0;
puts("ASF");
test_print();
return 0;
}
Makefile:
example:
#clang -o example example.c
#./example
.PHONY: example
Wondering why it's creating a segmentation fault when it is linked like this, and what I am doing wrong.
I have checked otool and with DYLD_PRINT_LIBRARIES=YES and it shows it is importing the dynamically linked libraries, but for some reason it's segmentation faulting when linked but works fine when it isn't linked.
Your problem is this, in example.h:
MYARRAY *collection;
Since both main.c and example.c include this file, you end up defining collection twice, which results in undefined behavior. You need to make sure you define each object only once. The details are relatively unimportant since anything can happen with undefined behavior, but what's probably happening is that main.c is allocating memory for one object, but the one example.c is using is still NULL. As mentioned in the comments, since you define collection in main.c your linker is able to build the executable without needing to look for that symbol in the dynamic library, so you don't get a link time warning about it being defined there too, and obviously there'd be no cause for a warning at the time you compile the library.
It works for you when you put everything in one file because obviously then you're not defining anything twice, anymore. The error itself is nothing to do with the fact you're using a dynamic library, although that may have made it harder to detect.
It would be better to define this in example.c and provide a constructor function, there's no need for main() to be able to access it directly. But if you must do this, then define it in example.c and just declare an extern identifier in the header file to tell main.c that the object is defined somewhere else.

Can't link to .so file on Mac with CMake

I'm working on a PHP 7 extension using Swig and am trying to link to libphp7.so. From my CMakeLists.txt file:
find_library(php7_lib php7 PATHS "/usr/local/Cellar/php/7.3.0/lib/httpd/modules" NO_DEFAULT_PATH)
target_link_libraries(navdb_php7_client_api ${php7_lib} dl)
But I get an error:
[100%] Linking CXX shared module .../lib/libnavdb_php7_client_api.so
...
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/usr/local/Cellar/php/7.3.0/lib/httpd/modules/libphp7.so' for architecture x86_64
The file I'm trying to link to:
$ file /usr/local/Cellar/php/7.3.0/lib/httpd/modules/libphp7.so
/usr/local/Cellar/php/7.3.0/lib/httpd/modules/libphp7.so: Mach-O 64-bit bundle x86_64
Any ideas on how to resolve this?
Although Apple recommends bundles be given the extension .bundle many developers give them the .so extension for the sake of cross-platform familiarity. On Linux, no distinction is made between a shared module (a bundle on MacOS) and a shared library (a dylib on MacOS.)
Understanding that, as ld states, you cannot link to an MH_BUNDLE on MacOS. It either needs to be a dylib to link it, or you need to load the .so using the dyld APIs.
This link gives an example of how to dynamically load a bundle on MacOS:
#include <stdio.h>
#import <mach-o/dyld.h>
int main( )
{
int the_answer;
int rc; // Success or failure result value
NSObjectFileImage img; // Represents the bundle's object file
NSModule handle; // Handle to the loaded bundle
NSSymbol sym; // Represents a symbol in the bundle
int (*get_answer) (void); // Function pointer for get_answer
/* Get an object file for the bundle. */
rc = NSCreateObjectFileImageFromFile("libanswer.bundle", &img);
if (rc != NSObjectFileImageSuccess) {
fprintf(stderr, "Could not load libanswer.bundle.\n");
exit(-1);
}
/* Get a handle for the bundle. */
handle = NSLinkModule(img, "libanswer.bundle", FALSE);
/* Look up the get_answer function. */
sym = NSLookupSymbolInModule(handle, "_get_answer");
if (sym == NULL)
{
fprintf(stderr, "Could not find symbol: _get_answer.\n");
exit(-2);
}
/* Get the address of the function. */
get_answer = NSAddressOfSymbol(sym);
/* Invoke the function and display the answer. */
the_answer = get_answer( );
printf("The answer is... %d\n", the_answer);
fprintf(stderr, "%d??!!\n", the_answer);
return 0;
}
I found out how/what to do from this link:
Clang and undefined symbols when building a library
The libphp7.so doesn't need to be linked to at compile time, run-time works fine. This can be enabled by setting a CXX_FLAG (see the link for details).

go run throes error " undefined reference to `dlopen'"

I am trying to integrate Golang script with existing C shared library.
The C shared library in turn loads other shared libraries at run time.
While I am trying to run
go run gotest.go
it throws error
./libtest.so: undefined reference to `dlopen'
./libtest.so: undefined reference to `dlclose'
./libtest.so: undefined reference to `dlerror'
./libtest.so: undefined reference to `dlsym'
collect2: error: ld returned 1 exit status
I have created separate C executable to load this libtest.so at run time and that is working properly.
Any idea what should be done to fix the issue?
I have tried following commands
sudo go build -compiler=gccgo -gccgoflags="-ltest" gotest.go
also tried the command
sudo go build -compiler=gccgo -gccgoflags="-ltest -ldl" gotest.go
Also tried the command
go run gotest.go
===============================================
Here is the code I am using
testapi.h
typedef Students{
char name[40];
int id;
} Student;
Student* getStudent();
test.c
#include <stdlib.h>
#include <stdio.h>
#include "mylib.h"
#include "testapi.h"
int rc = 0;
Student *s = 0;
Student* getStudent(){
rc = loadmylib(); //This function loads another shared library
if (!rc)
{
rc = initlib(); //This calls dlsym to get the necessary function from opened shared library
if (!rc)
{
s= (student *)malloc(sizeof(Student));
//use the function pointer received from dlsym to populate the Student struct 's'
}
}
return s;
}
I have following entries in my gotest.go file
package main
/*
#cgo CFLAGS: -I.
#cgo LDFLAGS: -L. -ltest -ldl
#include "testapi.h"
*/
import "C"
import (
"fmt"
)
type Student struct{
name string
id int
}
func main() {
st := C.getStudent()
fmt.Println("Name: ", string(st.name))
}
I have copied testapi.h, gotest.go, mylib.h, libmylib.so, libtest.so in the same directory.
Then run the command
go run gotest.go
It has thrown the error " error: undefined reference to 'getStudent' "
What am I doing wrong here?
Am I supposed to run command
sudo go build -compiler=gccgo -gccgoflags="-ltest" gotest.go

Curses Development Kit - DSO missing from command line

I am trying to compile the following on Ubuntu 14.04 but am receiving an error. Can anyone point me in the right direction? I have tried -lpthread which has no effect.
Compile:
gcc main.c -o terminal-app -lcdk -lpthread
main.c (copy pasted from here save for the <cdk/cdk.h> correction)
#include <cdk/cdk.h>
void main()
{
CDKSCREEN *cdkscreen;
CDKLABEL *demo;
WINDOW *screen;
char *mesg[4];
/* Initialize the Cdk screen. */
screen = initscr();
cdkscreen = initCDKScreen (screen);
/* Start CDK Colors */
initCDKColor();
/* Set the labels up. */
mesg[0] = "</31>This line should have a yellow foreground and a cyan background.<!31>";
mesg[1] = "</05>This line should have a white foreground and a blue background.<!05>";
mesg[2] = "</26>This line should have a yellow foreground and a red background.<!26>";
mesg[3] = "<C>This line should be set to whatever the screen default is.";
/* Declare the labels. */
demo = newCDKLabel (cdkscreen, CENTER, CENTER, mesg, 4, TRUE, TRUE);
/* Draw the label */
drawCDKLabel (demo, TRUE);
waitCDKLabel (demo, ' ');
/* Clean up */
destroyCDKLabel (demo);
destroyCDKScreen (cdkscreen);
endCDK();
exit (0);
}
Error:
/usr/bin/ld: /tmp/ccUtj1kg.o: undefined reference to symbol 'initscr'
//lib/x86_64-linux-gnu/libncurses.so.5: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Obviously, cdk requires ncurses to be directly supplied in command line. On my machine your test passes with:
gcc test.c -lcdk -lncurses
I use a makefile for compiling CDK in Linux (Debian Stable)
http://mrflash818.geophile.net/software/nc_834v5010generator/makefile
The parts I needed were two:
where to find the header files
CXXFLAGS := -Wall -g -I /usr/include/cdk
to link the CDK library
LDLIBS := -lcdk

Resources