I am trying to use libwebsocket to build up my WebSocket server and I need to used libmysql in my code. I have install the libmysql and able to use it but I don't know how to include it using cmake in CMakeList.txt
I have include it in my test-server.h
#include <mysql.h>
In my CMakeList.txt, I add this
INCLUDE_DIRECTORIES(/usr/include/mysql)//this is add to the begining
when I use "make" to make the file, I got the error message
CMakeFiles/test-server.dir/test-server/test-server.c.o: in function main:
test-server.c:(.text.startup+0x41): undefined reference to `mysql_init'
collect2: error: ld returned 1 exit status
Here is the original code of the CMakeList.txt
https://github.com/warmcat/libwebsockets/blob/master/CMakeLists.txt
The CMakeList.txt is provided by libwebsocket and I try to edit it with the follow code:
INCLUDE_DIRECTORIES(/usr/include/mysql)
Name: libwebsockets
Description: Websockets server and client library
Version: ${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACK AGE_VERSION_PATCH}
Libs: -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl -L\${libdir} -lwebsockets
Cflags: -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG -I\${includedir}"
Why I can not link the library?
What should I do in order to use libmysql in my libwebsocket server code?
I am using ubuntu 14.04 as OS.
I would recommend you to create your own CMakeLists.txt file.
It should takes care of your own code, because test-server.c is just an example that allow you to understand how to build your own server. In my opinion, it is not intend to be modified. But, of course, it is up to you to do so if you think it is easier.
So, now, if you really want to modify the example coming with libwebsockets, and want to keep the associated CMakeLists.txt file, then you could modify the create_test_app macro and modify calls to target_link_libraries (in addition to the modification you have already made regarding include path).
For example you could change:
target_link_libraries(${TEST_NAME} websockets)
by
target_link_libraries(${TEST_NAME} websockets mysqlclient)
It should be even better to take advantage of FindMysql.cmake to automatically find out what are the correct include paths and libraries locations.
Related
A directory teeming with demonstration files called ncurses-examples-20200725 is available here:
[ftp://ftp.invisible-island.net/ncurses-examples/current/ncurses-examples.tar.gz][1]
I wanted to study the workings of the form_driver_w example so I built the programs in accordance with the README file.
If I run ./form_driver_w, the result is a command line statement: "This program requires the wide-ncurses and forms library".
That outcome occurs because the following statement is not true:
#if USE_WIDEC_SUPPORT && USE_LIBFORM && (defined(NCURSES_VERSION_PATCH) && NCURSES_VERSION_PATCH >= 20131207)
Trying to trace how and where in the labyrinth of header files and compiler switches USE_WIDEC_SUPPORT is set to true is diabolically difficult. Furthermore, since the source code uses form_driver_w, I would have expected the compiler to link to ncursesw. However the compiler call is like this:
gcc -g -O2 -o form_driver_w ../ncurses-examples-20200725/form_driver_w.o ../ncurses-examples-20200725/popup_msg.o -L/lib64 -I. -I. -I../test -DHAVE_CONFIG_H -DDATA_DIR=\"/usr/local/share\" -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_XPG5 -g -O2 -DNCURSES_STATIC -lform -lmenu -lpanel -lncurses -lutil -lm
My Debian Bullseye installation includes a binary called form_driver_w in the /usr/lib/ncurses/examples/ directory. That binary runs correctly. I do not know how it was compiled.
Compiling and running form_driver_w must be a trivial task. Does anybody know how to do it?
You'd have to configure using ncursesw:
configure --with-screen=ncursesw
(and, of course, have the development library available).
The place to find this information is by running
configure --help
which lists a few options:
General Options:
--disable-stripping do not strip (debug info) installed executables
--enable-string-hacks work around bogus compiler/loader warnings
--with-pkg-config{=path} enable/disable use of pkg-config
--disable-echo do not display "compiling" commands
Curses Version-dependent Options:
--with-ncurses-wrap-prefix naming-prefix for ncurses wrapped-variables
--disable-widec disable checks for wide-character functions
--with-curses-dir=DIR directory in which (n)curses is installed
--with-screen=XXX use specified curses-libraries
--with-ncursesw use wide ncurses-libraries
--with-ncurses use ncurses-libraries
--with-pdcurses compile/link with pdcurses X11 library
--with-curses-colr compile/link with HPUX 10.x color-curses
--with-curses-5lib compile/link with SunOS 5lib curses
--with-Xaw3d link with Xaw 3d library
--with-Xaw3dxft link with Xaw 3d xft library
--with-neXtaw link with neXT Athena library
--with-XawPlus link with Athena-Plus library
--with-x use the X Window System
--with-x11-rgb=FILE file containing X11 rgb information (EPREFIX/lib/X11/rgb.txt)
--with-form-libname=XXX override form basename of library
--with-menu-libname=XXX override menu basename of library
--with-panel-libname=XXX override panel basename of library
--disable-panel disable checks for panel functions
--disable-menu disable checks for menu functions
--disable-form disable checks for form functions
Testing/development Options:
--enable-warnings test: turn on gcc compiler warnings
--with-dmalloc test: use Gray Watson's dmalloc library
--with-dbmalloc test: use Conor Cahill's dbmalloc library
--with-valgrind test: use valgrind
--disable-leaks test: free permanent memory, analyze leaks
--disable-rpath-hack don't add rpath options for additional libraries
I'm using ubuntu 14.04 and i'm trying to install the UHD device from the github but i'm getting an error that won't allow it to build.
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
willie.thompson#seb215-wks07:~/redhawk/USRP_UHD/cpp$ make
CXX USRP_UHD-USRP_UHD.o
CXX USRP_UHD-USRP_UHD_base.o
CXX USRP_UHD-main.o
CXX USRP_UHD-template_impl.o
CXXLD USRP_UHD
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
seb215-wks07:~/redhawk/USRP_UHD/cpp$
Am I doing something wrong here or is the issue with Ubuntu?
For now, you can edit the Makefile.am file to fix this. At the end of the USRP_UHD_LDADD line, add -luuid, then you should be able to rebuild it successfully.
The version of g++ used in Ubuntu14 is stricter than the version used in CentOS6. Luckily, g++ is providing a good hint about what the issue is.
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
It is basically saying "What you want is here in libuuid.so.1 but you didn't put it on the command line so I'm refusing to use it". While in CentOS6 g++ is less strict and links regardless, assuming that is what you wanted.
You have two options, one is the easy way out that works quick, one is a better long term solution:
1) Run make again in verbose mode, this will show you exactly what calls are being made and you can fix the offending call. Lets do that below:
make V=1
< ... a bunch of calls to g++ that work fine or nothing if these have already run prior .... >
g++ -Wall -D__x86_64__ -D__linux__ -D__OSVERSION__=2 -DENABLE_EVENTS=1 -I/var/lib/redhawk/core/include -I/var/lib/redhawk/core/include/ossie -I/var/lib/redhawk/core/share/idl -pthread -I/usr/include -I/var/lib/redhawk/core/include/frontend -I/var/lib/redhawk/core/include/redhawk -I/var/lib/redhawk/core/include/bulkio -I/var/lib/redhawk/core/include/ossie -g -O2 -Wall -o USRP_UHD USRP_UHD-USRP_UHD.o USRP_UHD-USRP_UHD_base.o USRP_UHD-main.o USRP_UHD-template_impl.o -L/var/lib/redhawk/core/lib64 -lossiecf -lossieidl -lCOS4 -lomniDynamic4 -lomniORB4 -lomnithread -L/usr/lib/x86_64-linux-gnu -lboost_thread -lboost_regex -lboost_system -L/var/lib/redhawk/core/lib64 -lfrontend-2.2.0 -lfrontendInterfaces -lbulkio-1.10 -lbulkioInterfaces -luhd -llog4cxx
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
Okay, so now we have the long ugly g++ call, we simply need to add "-luuid" to the list of linked libraries so we can tack that on at the end and voila! It will return without error. Note that we simply hand ran 1 of the g++ calls so for good measure run Make again in case there are any additional build steps; in this case there are not, it will simply say "nothing to be done"
2) A better fix! So the build files clearly need some fixing.
If we take a look at the configure.ac we see that there are calls like this one:
PKG_CHECK_MODULES([LIBUHD], [uhd >= 3.5.3])
What this is doing is saying "Check pkg-config for the module uhd, ensure it is of version >= 3.5.3 and store any build related info in a variables prefixed with LIBUHD so that I can use it later". Sounds like what we want. We can check to see if pkg-config is aware of libuuid by viewing all of the packages it knows about:
pkg-config --list-all
That will show us everything pkg-config knows about and we see that it is aware of uuid. So, lets add a line to configure.ac right below the check for the UHD driver and see what affect that has. My line looks like this:
PKG_CHECK_MODULES([LIBUUID], [uuid])
I put no version constraint. Okay, so now in order for that change to be incorporated we need to rerun the reconf script and then we can see the configure output.
./reconf
./configure
<....a bunch of stuff....>
checking for LIBUUID... yes
<....a bunch more stuff....>
That's new! We are now checking for the uuid library in our configure call and if you take a look at the config.log file, new variables have been added:
LIBUUID_CFLAGS='-I/usr/include/uuid '
LIBUUID_LIBS='-luuid '
Alright, almost there! Take a look at the Makefile.am file. These variables are used there and dictate the calls to g++. Append our newly made LIBUUID_CFLAGS and LIBUUID_LIBS variables to the end of the USRP_UHD_LDADD and USRP_UHD_CXXFLAGS variables like I've done below.
USRP_UHD_LDADD = $(PROJECTDEPS_LIBS) $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB) $(BOOST_REGEX_LIB) $(BOOST_SYSTEM_LIB) $(INTERFACEDEPS_LIBS) $(redhawk_LDADD_auto) $(LIBUHD_LIBS) $(LIBUUID_LIBS)
USRP_UHD_CXXFLAGS = -Wall $(PROJECTDEPS_CFLAGS) $(BOOST_CPPFLAGS) $(INTERFACEDEPS_CFLAGS) $(redhawk_INCLUDES_auto) $(LIBUHD_FLAGS) $(LIBUUID_CFLAGS)
Since we've changed the Makefile.am files, we need to rerun ./configure. Rule of thumb is that ./reconf creates your configure script from the configure.* files and ./configure creates the Makefile's from your Makefile.* files so if you edit a downstream file you need to rerun the upstream script.
Alright, now that we've done that things should work! We've added a system check for libuuid via pkg-config using the configure.ac file, stored the outcome in a variable and used that in our makefile template.
None of this is really unique to redhawk so if you'd like more information there is loads of documentation on the autotools build system and pkg-config.
I want to use CUDPP library in my project. I've downloaded sources from project page. Unfortunatly, when I ran "make", there was only static library build. I've looked into Makefile files and haven't found any dynamic lib configuration. I don't want to keep static library with the project - it's totally non-portable way.
My question is: how can I build .so dynamic library of CUDPP, without writing my own Makefile/compiling it manually? Maybe someone already did it?
EDIT: I've replaced "g++" with "g++ -fPIC", "gcc" with "gcc -fPIC" and "nvcc" with "nvcc -Xcompiler -fpic". When I unpack obj files from archive, and link them to shared lib, I've got no error. However, my application crashes at start, when linked with this library.
when you compile pass the flag -Xcompiler -fpic to nvcc. If you link against any cuda libraries make sure you've linked to the shared libs, otherwise you can't link it. Hopefully that's all you need.
Are you also using -shared to create the library? You shouldn't need to extract anything from an archive if it is working correctly.
If you run ldd on your executable it will show you what dynamic linking is required by the app and you can check that the -fPIC etc. worked correctly. Also make sure that the .so library is on your LD_LIBRARY_PATH (sorry if that's obvious, no harm in checking).
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install
How can I link a shared library function statically in gcc?
Refer to:
http://www.linuxquestions.org/questions/linux-newbie-8/forcing-static-linking-of-shared-libraries-696714/
You need the static version of the library to link it.
A shared library is actually an executable in a special format
with entry points specified (and some sticky addressing issues
included). It does not have all the information needed to
link statically.
You can't statically link a shared library (or dynamically link a static one).
The flag -static will force the linker to use static libraries (.a) instead of shared (.so) ones. But static libraries aren't always installed by default, so you may have to install the static library yourself.
Another possible approach is to use statifier or Ermine. Both tools take as input a dynamically linked executable and as output create a self-contained executable with all shared libraries embedded.
If you want to link, say, libapplejuice statically, but not, say, liborangejuice, you can link like this:
gcc object1.o object2.o -Wl,-Bstatic -lapplejuice -Wl,-Bdynamic -lorangejuice -o binary
There's a caveat -- if liborangejuice uses libapplejuice, then libapplejuice will be dynamically linked too.
You'll have to link liborangejuice statically alongside with libapplejuice to get libapplejuice static.
And don't forget to keep -Wl,-Bdynamic else you'll end up linking everything static, including libc (which isn't a good thing to do).
Yeah, I know this is an 8 year-old question, but I was told that it was possible to statically link against a shared-object library and this was literally the top hit when I searched for more information about it.
To actually demonstrate that statically linking a shared-object library is not possible with ld (gcc's linker) -- as opposed to just a bunch of people insisting that it's not possible -- use the following gcc command:
gcc -o executablename objectname.o -Wl,-Bstatic -l:libnamespec.so
(Of course you'll have to compile objectname.o from sourcename.c, and you should probably make up your own shared-object library as well. If you do, use -Wl,--library-path,. so that ld can find your library in the local directory.)
The actual error you receive is:
/usr/bin/ld: attempted static link of dynamic object `libnamespec.so'
collect2: error: ld returned 1 exit status
Hope that helps.
If you have the .a file of your shared library (.so) you can simply include it with its full path as if it was an object file, like this:
This generates main.o by just compiling:
gcc -c main.c
This links that object file with the corresponding static library and creates the executable (named "main"):
gcc main.o mylibrary.a -o main
Or in a single command:
gcc main.c mylibrary.a -o main
It could also be an absolute or relative path:
gcc main.c /usr/local/mylibs/mylibrary.a -o main
A bit late but ... I found a link that I saved a couple of years ago and I thought it might be useful for you guys:
CDE: Automatically create portable Linux applications
http://www.pgbovine.net/cde.html
Just download the program
Execute the binary passing as a argument the name of the binary you want make portable, for example: nmap
./cde_2011-08-15_64bit nmap
The program will read all of libs linked to nmap and its dependencias and it will save all of them in a folder called cde-package/ (in the same directory that you are).
Finally, you can compress the folder and deploy the portable binary in whatever system.
Remember, to launch the portable program you have to exec the binary located in cde-package/nmap.cde
Best regards
In gcc, this isn't supported. In fact, this isn't supported in any existing compiler/linker i'm aware of.