Cygwin OpenGL compiling returns undefined references to imp_iob - c++

I'm attempting to compile this tutorial http://www.opengl-tutorial.org/beginners-tutorials/tutorial-1-opening-a-window/ with Cygwin. I'm getting the following errors:
$ g++ main.cpp -o main -lm -lgl -lglut -lglew -lglfw -lopengl32 -lglu32 -lglaux
-lodbc32 -lodbccp32
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11a0): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11c8): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x11f0): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1394): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1661): undefined reference to `_imp___iob'
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o):win32_windo
w.c:(.text+0x1696): more undefined references to `_imp___iob' follow
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: /usr/lib/gc
c/i686-pc-cygwin/4.7.3/../../../libglfw.a(win32_window.o): bad reloc address 0x0
in section `.rdata'
collect2: error: ld returned 1 exit status
What may be causing this?

When you see unresolved symbols to _imp__, it implies you are trying to link against a library that was built to use a DLL at run-time. Technically, the problem is how the MSVC compiler mangles the import stub for __stdcall functions - it pre-fixes an underscore, which gcc is not expecting (e.g. _imp instead of imp).
cygwin/MinGW needs a little bit of extra help (either they must use a library that was compiled with gcc or the MSVC DLL-based import library must be altered). There is an article that explains this here.
However, the vast majority of the time the simpler solution is simply to link against the static linking version of your library. In the case of GLEW and glfw, they both ship with static libraries. You will need to define GLEW_STATIC and link against glew32s instead of glew. As for glfw, I am not as familiar - consult the documentation for glfw to find out how to do this.

Related

c++ files to include for boost : asio

I'm following this tutorial however it does not state which libaries I need to include in order to get boost to work,current options for links are:
-I/usr/include/opencv2 -I/usr/include/boost_1_55_0 -I/usr/include/boost_1_55_0/boost -O0 -g3 -Wall -c -fmessage-length=0
however this returns the following erro:
which states that it can't find asio, am I doing something wrong or was assio the wrong library to link to? Or is there any other way to find out. Note that this is my 2nd c++ project(through I have a lot of java experience) and first with the heavy use of libraries so details are somewhat required.
Removing boost/asio gave me the following errors:
make all
Building target: DisplayImage
Invoking: GCC C++ Linker
g++ -L/usr/include/opencv2 -L/usr/include/boost_1_55_0/boost -L/usr/include/boost_1_55_0 -L/usr/include/opencv2 -L/usr/lib -o "DisplayImage" ./src/Cap.o ./src/DisplayImage.o ./src/Filters.o ./src/sender.o -lopencv_imgproc -lopencv_highgui -lopencv_core
./src/sender.o: In function `__static_initialization_and_destruction_0':
/usr/include/boost_1_55_0/boost/system/error_code.hpp:222: undefined reference to `boost::system::generic_category()'
/usr/include/boost_1_55_0/boost/system/error_code.hpp:223: undefined reference to `boost::system::generic_category()'
/usr/include/boost_1_55_0/boost/system/error_code.hpp:224: undefined reference to `boost::system::system_category()'
./src/sender.o: In function `error_code':
/usr/include/boost_1_55_0/boost/system/error_code.hpp:323: undefined reference to `boost::system::system_category()'
./src/sender.o: In function `boost::asio::error::get_system_category()':
/usr/include/boost_1_55_0/boost/asio/error.hpp:224: undefined reference to `boost::system::system_category()'
collect2: ld returned 1 exit status
make: *** [DisplayImage] Error 1
Build Finished **
I use an ubuntu (x64) laptop if it matters.
Most of boost is implemented in what's called "header-only" code. Through the generous use of C++ templates, there is no actual library code to which your code needs to link. However, there are, as you've seen some actual libraries as well. Generally, the help you seek is probably here: http://www.boost.org/doc/libs/1_55_0/more/getting_started/unix-variants.html#link-your-program-to-a-boost-library
Your particular program uses the timer and system libraries and so you can probably use this command line to link your program:
g++ timer.cpp -o timer -lboost_timer -lboost_system
You can look at the bjam in boost/libs/asio/example/cpp03/tutorial/Jamfile.v2:
project
: requirements
<library>/boost/system//boost_system
<library>/boost/thread//boost_thread
<define>BOOST_ALL_NO_LIB=1
<threading>multi
<os>SOLARIS:<library>socket
<os>SOLARIS:<library>nsl
<os>NT:<define>_WIN32_WINNT=0x0501
<os>NT,<toolset>gcc:<library>ws2_32
<os>NT,<toolset>gcc:<library>mswsock
<os>NT,<toolset>gcc-cygwin:<define>__USE_W32_SOCKETS
<os>HPUX,<toolset>gcc:<define>_XOPEN_SOURCE_EXTENDED
<os>HPUX:<library>ipv6
;
You can see that they build all the tutorial steps with
-lboost_system -lboost_thread -DBOOST_ALL_NO_LIB=1
on linux

__imp link errors using g++ running under mingw

I have a simple socket program that I'm trying to compile using g++ running in mingw (both the latest versions) on a Win8 system. I'm getting the common linker errors
undefined reference to `__imp_socket'
undefined reference to `__imp_gethostbyname'
I've tried adding -lws2_32 with no luck; i.e. it still can't find the references. Can someone suggest something else I might be missing?
Here's the full output:
G:\source\kak>g++ -o ./test_client -lws2_32 test_client.C
C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o:test_client.C:(.text+0x4f): undefined reference to `__imp_inet_addr'
C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o:test_client.C:(.text+0x6b): undefined reference to `__imp_socket'
C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o:test_client.C:(.text+0x8b): undefined reference to `__imp_connect'
d:/program files/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\kenkahn\AppData\Local\Temp\ccDZTr9b.o: bad reloc address 0xc in section `.xdata'
collect2.exe: error: ld returned 1 exit status
Try putting the -lws2_32 after the test_client.C parameter. The linker of gcc (ld) is touchy about the order of linkable things, this is probably why it doesn't find your imported functions at link time.

undefined references in libpthread and libc

I'm having trouble compiling some examples in a odbc sdk. After some time mingling with the library order, I somehow managed to get the number of undefined references to just a handful of them.
Sadly, I can't figure out how to get rid of the remaining ones. Here's the command that's failing:
g++ -Wall -z defs -m64 -DSIMBA -D_REENTRANT -fPIC -O0 -g -shared Common/TabbedUnicodeFileReader_Linux_x8664_debug.cpp.o Core/QSConnection_Linux_x8664_debug.cpp.o Core/QSDriver_Linux_x8664_debug.cpp.o Core/QSEnvironment_Linux_x8664_debug.cpp.o Core/QSStatement_Linux_x8664_debug.cpp.o DataEngine/QSDataEngine_Linux_x8664_debug.cpp.o DataEngine/QSMetadataHelper_Linux_x8664_debug.cpp.o DataEngine/QSTable_Linux_x8664_debug.cpp.o DataEngine/QSTableUtilities_Linux_x8664_debug.cpp.o DataEngine/QSTypeInfoMetadataSource_Linux_x8664_debug.cpp.o Common/QSTableMetadataFile_Unix_Linux_x8664_debug.cpp.o Common/QSUtilities_Unix_Linux_x8664_debug.cpp.o Main_Unix_Linux_x8664_debug.cpp.o -Wl,--no-undefined -Wl,--no-allow-shlib-undefined -Wl,--whole-archive,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaDSI_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaSupport_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libAEProcessor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libCore_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libDSIExt_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libExecutor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libParser_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaODBC_debug.a -Wl,--no-whole-archive -Wl,--soname=../Bin/Linux_x8664/libQuickstart_debug.so -L/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//ThirdParty/icu/Linux_x8664/lib -licuuc_simba64 -licudata_simba64 -licui18n_simba64 -lpthread -lm -lc -ldl -Wl,--version-script=exports_Linux.map -o ../Bin/Linux_x8664/libQuickstart_debug.so
Edit: Missing symbols
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libdl.so: undefined reference to `_dl_rtld_di_serinfo#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls_init#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__libc_stack_end#GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_get_tls_static_info#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__tls_get_addr#GLIBC_2.3'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_deallocate_tls#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_argv#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `__libc_enable_secure#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global_ro#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_make_stack_executable#GLIBC_PRIVATE'
Fixed:
Removing -Wl,--no-allow-shlib-undefined seemed to do the trick. The built shared library seems to work perfectly.
I had a similar issue with a completely separate application. The following compile time flag worked for me:
-B/usr/lib/gold-ld/
which i found at:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/885927
I'm using gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 I was trying to compile with lto.
You do a very common newbie mistake. you place the libraries to link with in the middle or the beginning of the command line. The linker GCC uses needs dependencies in reverse order. That means if you have an source/object file S using a function in library L, the file A has to be before the library L on the command line.
In short, put the libraries (-lm -lc -ldl) last on the command line instead.
If linker fails to resolve all referenced symbols then this can be a result of wrong order of provided libraries. If you are not sure what is the correct order then put archives in "--start-group archives --end-group" which according to ld manual will force linker to search the specified archives repeatedly until no new undefined references are created. But pay attention to a performance cost.
The OP mentioned "Removing -Wl,--no-allow-shlib-undefined" helped.
In my case I had to add the opposite:
-Wl,--allow-shlib-undefined
(Everything was working fine with an older version of GCC)

Undefined references when linking gsl library in eclipse

I'm trying to link an open source project that uses GSL and I get undefined references in libgsl. I'm using eclipse and I've added -lgslcblas -lgsl to the libraries setting. What am I missing?
g++ -L/home/erwin/ochack/bin/opencog/spatial -L/home/erwin/ochack/bin/opencog/persist/sql -L/home/erwin/ochack/bin/opencog/guile -L/home/erwin/ochack/bin/opencog/util -L/home/erwin/ochack/bin/opencog/persist/xml -o "ocserver" ./opencog/server/Agent.o ./opencog/server/BaseServer.o ./opencog/server/BuiltinRequestsModule.o ./opencog/server/CogServer.o ./opencog/server/CogServerMain.o ./opencog/server/ConsoleSocket.o ./opencog/server/DataRequest.o ./opencog/server/ExitRequest.o ./opencog/server/HelpRequest.o ./opencog/server/ListRequest.o ./opencog/server/LoadModuleRequest.o ./opencog/server/LoadRequest.o ./opencog/server/NetworkServer.o ./opencog/server/Request.o ./opencog/server/SaveRequest.o ./opencog/server/ServerSocket.o ./opencog/server/ShutdownRequest.o ./opencog/server/SleepRequest.o ./opencog/server/SystemActivityTable.o ./opencog/server/UnloadModuleRequest.o ./opencog/atomspace/Atom.o ./opencog/atomspace/AtomSpace.o ./opencog/atomspace/AtomSpaceAsync.o ./opencog/atomspace/AtomSpaceImpl.o ./opencog/atomspace/AtomSpaceInit.o ./opencog/atomspace/AtomTable.o ./opencog/atomspace/AttentionBank.o ./opencog/atomspace/AttentionValue.o ./opencog/atomspace/ClassServer.o ./opencog/atomspace/CompositeTruthValue.o ./opencog/atomspace/CountTruthValue.o ./opencog/atomspace/FixedIntegerIndex.o ./opencog/atomspace/Handle.o ./opencog/atomspace/HandleEntry.o ./opencog/atomspace/HandleIterator.o ./opencog/atomspace/HandleSeqIndex.o ./opencog/atomspace/HandleSet.o ./opencog/atomspace/HandleTemporalPair.o ./opencog/atomspace/HandleTemporalPairEntry.o ./opencog/atomspace/HandleToTemporalEntryMap.o ./opencog/atomspace/ImportanceIndex.o ./opencog/atomspace/IndefiniteTruthValue.o ./opencog/atomspace/Link.o ./opencog/atomspace/LinkIndex.o ./opencog/atomspace/NameIndex.o ./opencog/atomspace/Node.o ./opencog/atomspace/NodeIndex.o ./opencog/atomspace/NullTruthValue.o ./opencog/atomspace/PredicateIndex.o ./opencog/atomspace/SimpleTruthValue.o ./opencog/atomspace/SpaceServer.o ./opencog/atomspace/StatisticsMonitor.o ./opencog/atomspace/StringIndex.o ./opencog/atomspace/TLB.o ./opencog/atomspace/TargetTypeIndex.o ./opencog/atomspace/Temporal.o ./opencog/atomspace/TemporalEntry.o ./opencog/atomspace/TemporalMap.o ./opencog/atomspace/TemporalTable.o ./opencog/atomspace/TemporalToHandleSetMap.o ./opencog/atomspace/TimeServer.o ./opencog/atomspace/Trail.o ./opencog/atomspace/TruthValue.o ./opencog/atomspace/TypeIndex.o ./opencog/atomspace/VersionHandle.o ./opencog/atomspace/ZMQMessages.pb.o -lboost_filesystem -lpersist -lsmob -lgslcblas -lgsl -lboost_signals -lboost_thread -lxml -lutil -lSpaceMap -lzmq -lboost_system -lprotobuf
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_zher2k'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_strsv'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_zdotc_sub'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_dtrsm'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_zhemm'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_sgemv'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libgsl.so: undefined reference to `cblas_strmm'
etc...
I found the solution: apparently the order of the libraries is important: -lgsl -lgslcblas works.
Potentially, there are lots of things that could be wrong here.
Have you made sure that you've added the libraries properly in Eclipse? For instance, you shouldn't specify -lgsl in Paths and Symbols -> Libraries. Eclipse adds the preceding -l itself so all you specify is gsl.
Have you added the library paths in the build variant that you're actually trying to run? You may, for instance, have specified library paths only for the Debug variant when you're trying to get a Release variant build going.
Alternatively, (and this is really just a guess), it's reasonably common for scientific libraries to allow you to use an external version of BLAS. Sometimes their configuration settings even insist on external BLAS as a default. Does passing -lcblas as a link option help out with these errors?

Linking error when upgrading from lua 4.0.1 to 5.1.4

I'm working on a really old source code (compiled in Red Hat). Before it had lua-4.0.1 so I just compiled the latest lua (lua-5.1.4) and installed it in the same directory as the old one. The implementation isn't very big so there wasn't much to change except a few function names and I had to include "lauxlib.h" to get it to compile. It compiles without any problems but it gives these linking errors.
/usr/local/lib/liblua.a(loadlib.o): In function `ll_load':
loadlib.o(.text+0x19): undefined reference to `dlopen'
loadlib.o(.text+0x2a): undefined reference to `dlerror'
/usr/local/lib/liblua.a(loadlib.o): In function `ll_sym':
loadlib.o(.text+0x52): undefined reference to `dlsym'
loadlib.o(.text+0x63): undefined reference to `dlerror'
/usr/local/lib/liblua.a(loadlib.o): In function `ll_unloadlib':
loadlib.o(.text+0x8): undefined reference to `dlclose'
Basically all the paths are correct but I use the same flags for the compiler as the old one, I havent changed the makefile at all.
-static -lpthread -lnsl -lutil -ldl -lmysqlclient -llua -llualib -lz -lcppunit
The ldl flag is already there.
I just want to know things to try. Everything is appreciated. This is driving me insane.
Place -ldl at the end of the liner command. The order is important.
The linker searches for libraries fulfilling an unreferenced symbol only in libs which are standing more right on the command line. Your new liblua.a now uses dlopen and friends, while the older didn't. Since -ldl is left of -llua, the linker does not use libdl to link the lua references.