This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
boost::asio ssl linking error
I am having issues with undefined symbols. My boost installation is fine as I have used it for other projects. I understand that I need OpenSSL installed, So installed it in the following way.
I then ran the following commands with VS2010 command prompt with the extracted OpenSSL source (most recent from openssl site) as the working directory.
perl Configure VC-WIN64A no-shared no-idea // I don't trust this.
ms\do_win64a
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak install
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
The source file is just the boost example. http://www.boost.org/doc/libs/1_52_0/doc/html/boost_asio/example/ssl/client.cpp
My VS2010 project is setup as follows.
C/C++ > General > Addition Include Directories
E:\libraries\boost_1_49_0 //as used in past projects
E:\usr\local\ssl\include //just installed
Linker > General > Addition Library Directories
E:\libraries\boost_1_49_0\stage\lib
E:\usr\local\ssl\lib
Linker > Input > Addition Directories
libeay32.lib
I thought that it might must have been boost tripping out. So I tried an SSL crypto example and that had undefined symbols.
Errors in a text file
OS is Windows 7 64Bit
I was trying to build a 32bit program with the 64 bit libs.
I changed the following from above to build the 64 bit version
perl Configure VC-WIN64A no-asm --prefix=\Dir\for\64\bit\ssl -DUNICODE -D_UNICODE
ms\do_win64a.bat
then nmake as normal
Related
I'm using Solus Linux with G++ and whenever I build the default console project in CodeLite I get the following output
/bin/sh -c '/usr/bin/make -j4 -e -f Makefile'
/bin/sh: /usr/bin/make: No such file or directory
====0 errors, 0 warnings====
I checked and make does not exist in /usr/bin in-fact, the most promising thing I found in this directory was a file called codelite-make
Here are the options I selected at project creation
Category: Console
Type: Simple executable (g++)
Compiler: GCC
Debugger: GNU gdb debugger
Build System: CodeLite Make Generator
Any help is greatly appreciated
You need to use your package manager for your linux OS to install make and now glibc and possibly other parts of your toolchain. CodeLite does not provide these.
I'm new to C/C++ and am trying to build and run ttwatch from github locally on an Ubuntu machine (Trusty Tahr). Instructions include installing some libraries first: cmake, openssl, curl, libusb, and include a note to install the "-dev" versions (eg. libssl-dev, libcurl-dev, libusb-1.0-0-dev). I'm having some trouble with libusb. I see questions about this all over the internet, but haven't yet found a solution that works.
Running cmake . appears to work fine:
meowmeow#kittytown:~/code/ttwatch$ cmake .
-- Enabled daemon function
-- Found libusb-1.0:
-- - Includes: /usr/include/libusb-1.0
-- - Libraries: /usr/lib/x86_64-linux-gnu/libusb.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/meowmeow/code/ttwatch
But running make shows that libusb is not being located properly:
meowmeow#kittytown:~/code/ttwatch$ make
[ 42%] Built target libttbin
[ 42%] Built target libttwatch
[ 42%] Built target ttbincnv
[ 42%] Built target ttbinmod
[ 42%] Built target manifest
Linking CXX executable ttwatch
CMakeFiles/ttwatch.dir/src/ttwatch.c.o: In function `main':
/home/meowmeow/code/ttwatch/src/ttwatch.c:1618: undefined reference to `libusb_init'
/home/meowmeow/code/ttwatch/src/ttwatch.c:1796: undefined reference to `libusb_exit'
...
If I check /usr/includes/, I see libusb:
meowmeow#kittytown:~/code/ttwatch$ ls /usr/include/libusb-1.0/libusb.h
/usr/include/libusb-1.0/libusb.h
And dpkg shows:
meowmeow#kittytown:~/code/ttwatch$ dpkg -L libusb-1.0-0-dev
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/libusb-1.0.pc
/usr/lib/x86_64-linux-gnu/libusb-1.0.a
/usr/share
/usr/share/doc
/usr/share/doc/libusb-1.0-0-dev
/usr/share/doc/libusb-1.0-0-dev/copyright
/usr/include
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h
/usr/lib/x86_64-linux-gnu/libusb-1.0.so
/usr/share/doc/libusb-1.0-0-dev/README
/usr/share/doc/libusb-1.0-0-dev/changelog.Debian.gz
meowmeow#kittytown:~/code/ttwatch$ dpkg -L libusb-1.0-0
/.
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libusb-1.0-0
/usr/share/doc/libusb-1.0-0/README
/usr/share/doc/libusb-1.0-0/copyright
/usr/share/doc/libusb-1.0-0/changelog.Debian.gz
/lib/x86_64-linux-gnu/libusb-1.0.so.0
The file ttwatch/includes/libttwatch.h includes libusb as #include <libusb.h>, and I've tried modifying that to #include <libusb-1.0/libusb.h>, in hopes of better matching my /usr/includes/ files, but that didn't change the error output.
Any help would be greatly appreciated!
EDIT:
Using make VERBOSE=1does show -lusb, and not -lusb-1.0:
...
/usr/bin/c++ -g CMakeFiles/ttwatch.dir/src/ttwatch.c.o CMakeFiles/ttwatch.dir/src/log.c.o CMakeFiles/ttwatch.dir/src/options.c.o CMakeFiles/ttwatch.dir/src/json.c.o CMakeFiles/ttwatch.dir/src/download.c.o CMakeFiles/ttwatch.dir/src/firmware.c.o CMakeFiles/ttwatch.dir/src/misc.c.o CMakeFiles/ttwatch.dir/src/get_activities.c.o CMakeFiles/ttwatch.dir/src/update_gps.c.o CMakeFiles/ttwatch.dir/src/set_time.c.o -o ttwatch -rdynamic libttwatch.a libttbin.a -lusb -lssl -lcrypto -lcurl
And libusb.so appears to exist:
meowmeow#kittytown:~/code/ttwatch$ dpkg-query -S /usr/lib/x86_64-linux-gnu/libusb.so
libusb-dev: /usr/lib/x86_64-linux-gnu/libusb.so
I tried uninstalling libusb-dev (sudo apt-get remove libusb-dev) and installed libusb-1.0 (sudo apt-get install libusb-1.0) to see if that would solve the issue. I now have a /usr/lib/x86_64-linux-gnu/libusb-1.0.so (note the 1.0) instead, but am now getting this from make:
make[2]: *** No rule to make target /usr/lib/x86_64-linux-gnu/libusb.so', needed by ttwatch'. Stop.
I was not aware that Debian has the packages libusb-dev and
libusb-1.0-dev. From the package information I cannot tell why there are 2
packages for the same library, perhaps libusb-dev is an older version with a
different API and other packages might still have that as a dependency. So
removing the package might not be a good idea, unless you don't care/need
packages depending on libusb-dev, in which case you can do apt-get purge
libusb-dev && apt-get autoremove. Be ware that this might uninstall
packages that you need. So do it only if you know what you are doing.
I did not expect that Debian allows you to install both packages at the same
time, but this could be if the APIs of both libraries are different and don't
conflict with each other.
This seems to confuse cmake, which somehow cannot handle when both libraries
are simultaneously installed. I've gone through the issues page and I
haven't found an issue relating to that. So if you cannot manage to build it,
I'd suggest that you go to the issue page, if you don't have an github
account, create one and leave a bug report about building the package when
libusb-dev and libusb-1.0-dev are simultaneously installed.
Another option would be to make a small modification in the file cmake_modules/FindLibUSB.cmake before you do
$ mkdir build && cd build
$ cmake ..
Find the line find_library(LIBUSB_1_LIBRARY, on the current stable version it is line 62. The next line is NAMES
and the next line is usb-1.0 usb. Remove the usb from that, so that
find_library only searches for libusb-1.0. Save the file and then you can do
$ mkdir build && cd build
$ cmake ..
This should fix the problem.
I'm learning to use wxWidget 2.8.12 with Codeblocks 12.11. I have followed the instructions on this site to install wxWidgets and Codeblocks:
http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef
When I try to create the project and run the demo app I get the error:
fatal error: wx/setup.h: No such file or directory
The following picture will show this better:
I have followed the instructions, but still I get the error...what seems to be the problem? :(
Thnx for any help
P.S.
Here is an overview what I have done:
1) I downloaded Codeblocks including MinGW (codeblocks-12.11mingw-setup.exe)
http://www.codeblocks.org/downloads/26#windows and I have installed them using the .exe file
2) I have edited my User PATH environment variable to according to the reference page I have used
3) I have downloaded wxWidgets installer from this link and installed it:
http://sourceforge.net/projects/wxwindows/files/2.8.12/wxMSW-2.8.12-Setup.exe/download?use_mirror=garr
4) I have entered the directory C:\<wxWidgets root>\build\msw and inputted the following command in command prompt:
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1 UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport
After letting wxWidgets build and trying to run my demo app I get the error I mentioned in Codeblocks :(
NOTICE FUTURE READERS: Install wxWidgets to a directory without whitespace in the path name! Otherwise this will cause trouble
Please have a look at the Below Link which i have put.It will be very useful.I have also installed wxWidget 2.8.12 with Codeblocks 12.11 using This Link.
Setting up wxWidgets(2.9.4) with Code::Blocks(12.11) in Windows
Type These below steps in Command Prompt after you finish installing the wxWidgets2.8.12 and CODEBLOCKS 12.11.
gcc -v
mingw32-make -v
cd /D C:\wxWidgets-2.8.12\build\msw
mingw32-make -f makefile.gcc clean
mingw32-make -f makefile.gcc BUILD=debug SHARED=0 MONOLITHIC=1 UNICODE=1
mingw32-make -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1 UNICODE=1
If the problem still persists after doing all the above steps then You're missing an important compiler search path in your build options.
Make sure you choose the correct wxWidgets build configuration when running the wxWidgets project wizard.
If re-running the wizard isn't an option, then open your project's build options and add "$(#wx.lib)\gcc_dll\mswu" (assuming a monolithic Unicode DLL build) to the compiler search paths.
I failed to compile qt shared library(64 bit) on windows using various versions of cmake. I think am making some mistakes in selecting cmake options. Can any one point me to some tutorials or tell the steps to be followed. Thanks in advance. (I can't use visual studio for this.)
This post worked for me :
#ECHO OFF
rmdir /Q /S C:\Qt\qt-git-build
mkdir C:\Qt\qt-git-build
cd C:\Qt\qt-git-build
..\qt-git\configure -opensource -mp -qt-zlib
nmake
nmake qdoc3
editbin /STACK:0x200000 bin\qdoc3.exe
nmake docs
nmake install
nmake clean
cd ..
After following the instructions in INSTALL.W64 I have two problems:
The code is still written to the "out32" folder. I need to be able to link to both 32-bit and 64-bit versions of the library on my workstation, so I don't want the 64-bit versions to clobber the 32-bit libs.
The output is still 32-bit! This means that I get "unresolved external symbol" errors when trying to link to the libraries from an x64 app.
To compile the static libraries (both release and debug), this is what you need to do:
Install Perl - www.activestate.com
Run the "Visual Studio 2008 x64 Cross Tools Command Prompt" (Note: The regular command prompt WILL NOT WORK.)
Configure with
perl Configure VC-WIN64A no-shared no-idea
Run: ms\do_win64a
EDIT ms\nt.mak and change "32" to "64" in the output dirs:
# The output directory for everything intersting
OUT_D=out64.dbg
# The output directory for all the temporary muck
TMP_D=tmp64.dbg
# The output directory for the header files
INC_D=inc64
INCO_D=inc64\openssl
EDIT ms\nt.mak and remove bufferoverflowu.lib from EX_LIBS if you get an error about it.
Run: nmake -f ms\nt.mak
EDIT the ms\do_win64a file and ADD "debug" to all lines, except the "ml64" and the last two lines
Run: ms\do_win64a
Repeat steps 4 and 5
EDIT the ms\nt.mak file and ADD /Zi to the CFLAG list!
Run: nmake -f ms\nt.mak
I solved the problem this way, using the 1.0.1c source:
Add this block to util/pl/VC-32.pl, just before the $o='\\'; line.
if ($debug)
{
$ssl .= 'd';
$crypto .= 'd';
}
Add this block to util/pl/VC-32.pl, just before the if ($debug) line.
if ($FLAVOR =~ /WIN64/)
{
$out_def =~ s/32/64/;
$tmp_def =~ s/32/64/;
$inc_def =~ s/32/64/;
}
Then build all varieties:
setenv /x86 /release
perl Configure VC-WIN32 --prefix=build -DUNICODE -D_UNICODE
ms\do_ms
nmake -f ms\ntdll.mak
setenv /x64 /release
perl Configure VC-WIN64A --prefix=build
ms\do_win64a.bat
nmake -f ms\ntdll.mak
setenv /x86 /debug
perl Configure debug-VC-WIN32 --prefix=build -DUNICODE -D_UNICODE
ms\do_ms
move /y ms\libeay32.def ms\libeay32d.def
move /y ms\ssleay32.def ms\ssleay32d.def
nmake -f ms\ntdll.mak
setenv /x64 /debug
perl Configure debug-VC-WIN64A --prefix=build
ms\do_win64a.bat
move /y ms\libeay32.def ms\libeay32d.def
move /y ms\ssleay32.def ms\ssleay32d.def
nmake -f ms\ntdll.mak
Use Conan. It is very simple to install and use.
You can request the files ready for use. For example for Linux x64 or usage with Visual Studio 2012. Here a sample instruction:
conan install OpenSSL/1.0.2g#lasote/stable -s arch="x86_64" -s build_type="Debug" -s compiler="gcc" -s compiler.version="5.3" -s os="Linux" -o 386="False" -o no_asm="False" -o no_rsa="False" -o no_cast="False" -o no_hmac="False" -o no_sse2="False" -o no_zlib="False" ...
According to the official documentation:
"You may be surprised: the 64bit artefacts are indeed output in the out32* sub-directories and bear names ending *32.dll. Fact is the 64 bit compile target is so far an incremental change over the legacy 32bit windows target. Numerous compile flags are still labelled "32" although those do apply to both 32 and 64bit targets."
So the first answer is no longer necessary.
Instructions can be found here:
https://wiki.openssl.org/index.php/Compilation_and_Installation#W64
At the time of writing this how-to the most recent version of OpenSSL is 1.1.1a.
Environment:
Windows 10
MS Visual Studio 2017
Prerequisites:
Install ActivePerl - Community edition is fine
Install NASM
Make sure both Perl and NASM are in PATH environment variable.
Compiling x64:
Open x64 Native Tools Command Prompt
perl Configure VC-WIN64A --prefix=e:\projects\bin\OpenSSL\vc-win64a --openssldir=e:\projects\bin\OpenSSL\SSL
nmake
nmake test
nmake install
Step 4 is optional.
Compiling x86:
Open x86 Native Tools Command Prompt
perl Configure VC-WIN32 --prefix=e:\projects\bin\OpenSSL\vc-win32 --openssldir=e:\projects\bin\OpenSSL\SSL
nmake
nmake test
nmake install
Step 4 is optional.
If you're building in cygwin, you can use the following script, assume MSDEVPATH has already been set to your Visual Studio dir
echo "Building x64 OpenSSL"
# save the path of the x86 msdev
MSDEVPATH_x86=$MSDEVPATH
# and set a new var with x64 one
MSDEVPATH_x64=`cygpath -u $MSDEVPATH/bin/x86_amd64`
# now set vars with the several lib path for x64 in windows mode
LIBPATH_AMD64=`cygpath -w $MSDEVPATH_x86/lib/amd64`
LIBPATH_PLATFORM_x64=`cygpath -w $MSDEVPATH_x86/PlatformSDK/lib/x64`
# and set the LIB env var that link looks at
export LIB="$LIBPATH_AMD64;$LIBPATH_PLATFORM_x64"
# the new path for nmake to look for cl, x64 at the start to override any other msdev that was set previously
export PATH=$MSDEVPATH_x64:$PATH
./Configure VC-WIN64A zlib-dynamic --prefix=$OUT --with-zlib-include=zlib-$ZLIB_VERSION/include --with-zlib-lib=zlib-$ZLIB_VERSION/x64_lib
# do the deed
ms/do_win64a.bat
$MSDEVPATH_x86/bin/nmake -f ms/ntdll.mak ${1:-install}
The build instructions have changed since this question was originally asked. The new instructions can be found here. Note that you will need to have perl and NASM installed, and you will need to use the developer command prompt.
You can also use MSYS+mingw-w64:
1) download and extract msys to C:\msys
2) download and extract mingw-w64 to c:\mingw64
3) run msys postinstall script. When it asks for your mingw installation, point it to C:\mingw64\bin
4) Extract an openssl daily snapshot (1.0.0 release has a bug). In the source dir run
configure mingw64
make
make check
make install
5) openssl is installed to /local/