C/C++ ftplib: Undefined reference to _imp__FtpInit - c++

I am trying to use a C/C++ FTP library (>here's the website). When I try to call the FtpInit() function I get a compilation error telling me that there is an undefined reference to _imp__FtpInit. This is what I'm trying to compile:
#include "ftplib/ftplib.h"
int main()
{
FtpInit();
return 0;
}

Did you remember to set your -L library path to the location where you installed the library, and use -lftplib (or similar depending on the actual library file's name) to link the library?

For Visual Studio, add the .lib file to the "Additional Dependencies" setting in project properties/Linker/Input.
You may also need to set "Additional Library Directories" in Project Properties/Linker/General

Related

Setting up a library in Eclipse CDT

I am creating a project which needs to use the libnoise headers. However I am having difficulty compiling.
I have put the headers into my src/ directory of my project, so I am able to include them with
#include "noise/noise.h"
#include "noise/noisegen.h"
#include "noiseutils.h"
But when I try and create a Perlin module noise::module::Perlin perlinModule;, I get the following compilation error:
PROJECTDIR\bin/../src/libnoise_wrapper.cpp:66: undefined reference to `noise::module::Perlin::Perlin()'
./src/libnoise_wrapper.o: In function `~Perlin':
PROJECTDIR\bin/../src/noise/module/perlin.h:160: undefined reference to `vtable for noise::module::Perlin'
PROJECTDIR\bin/../src/noise/module/perlin.h:160: undefined reference to `noise::module::Module::~Module()'
PROJECTDIR\bin/../src/noise/module/perlin.h:160: undefined reference to `vtable for noise::module::Perlin'
PROJECTDIR\bin/../src/noise/module/perlin.h:160: undefined reference to `noise::module::Module::~Module()
I have created a Project Include reference to the /src/noise folder as well as noiseutils.h file (which is in the src/ directory itself).
Are there any other configurations I am missing?
"I have put the headers into my src/ directory of my project, so I am able to include them with "
That's not the usual way to do! You should have an installation of this library in your environment (there are some instructions how to do this for your particular case available in this tutorial from the libnoise online documentation), and add the additional include paths to search using the
Project Properties->C/C++ Build->Settings-><actual C++ Compiler>->Includes->Include paths (-I)
settings.
"Are there any other configurations I am missing?"
Check the
Project Properties->C/C++ Build->Settings-><actual toolchain linker>->Libraries
properties page.
You'll need to provide noise in the Libraries list there, and eventually an additional Library search path pointing to the actual libs installation. The latter depends on how and where you have the libnoise installed in your environment.

undefined reference to '_WSAStartup#8'. How to link libraries with NetBeans?

I use NetBeans, Windows and Cygwin with G++ compiler.
I'm examining Windows Sockets 2. I do everything that is written in MS manual. I have a code (mostly from this manual):
#include <winsock2.h>
#include <ws2tcpip.h>
#include <cstdlib>
#include <iostream>
#pragma comment(lib, "Ws2_32.lib")
int main() {
WSADATA wsaData;
int iResult;
// Initialize Winsock
iResult = WSAStartup(MAKEWORD(2,2), &wsaData);
if (iResult != 0) {
printf("WSAStartup failed: %d\n", iResult);
return 1;
}
else cout << "Initialization OK.";
return 0;
}
And I have a problem when I try to run the project:
undefined reference to `_WSAStartup#8'
I understand that Ws2_32.lib is missing. This is because I do not have Windows SDK installed. But before installing it I want to try out tools that Cygwin offers. It has all the w32api header files, I have them in:
C:\cygwin\usr\include\w32api
And it has some w32api almost .lib files in the directory:
C:\cygwin\lib\w32api
But all these lib files are different, they have .a extension and a little bit different name, like:
libws2_32.a // in Cygwin
vs.
ws2_32.lib // in Windows
When I use Cygwin terminal to create an .exe file, everything works fine. The commands I input are:
cd C:\\c++\\myProgram // go to the dir
g++ myProgram.cpp -lws2_32 // compile using -l option to link libws2_32.a
And after it I get a.exe file. I run it and it works:
./a.exe // Initialization OK.
But as I said I use NetBeans. And if I try to run the project from NB ([F6] button) I always have this error undefined reference to '_WSAStartup#8'.
I've tried already everything I could find on NB forums. I've tried to link libws2_32.a to my project this way. I go to:
File -> Project Properties -> Linker -> Libraries
And there are three options:
Add Library...
Add Library File...
Add Option...
I've tried them all. I've tried to link both just Add Library... and Add Library File.... I've also tried to add such an option in the Add Option... button:
Add Option... -> Other option -> // and I input here "-lws2_32"
But whatever I do I can't run the project from NB, I get error undefined reference to '_WSAStartup#8'.
So it seems that it is not a problem (error) in the code. It seems that the problem is with NB, with its possibility to link libraries. Or I do wrong steps to attach them to the project.
So my questions are:
1) What do I do wrong? How may I run the project right from NB? I didn't try to install Windows SDK, I want to try with Cygwin tools as it has such kind of tools.
2) What is the difference between Windows .lib files and Cygwin .a files? Is it better to install Windows SDK and just forget about those .a files? Everything I could find so far about them on Cygwin site is this:
The import library is a regular UNIX-like .a library, but it only
contains the tiny bit of information needed to tell the OS how your
program interacts with ("imports") the dll. This information is linked
into your .exe. This is also generated by dlltool.
3) Is it possible to use #pragma comment(lib, "libws2_32.a") to link .a files? I've tried but didn't get success results.
1) What do I do wrong? How may I run the project right from NB? I didn't try to install Windows SDK, I want to try with Cygwin tools as it has such kind of tools.
Try this: http://forums.netbeans.org/ptopic44959.html
2) What is the difference between Windows .lib files and Cygwin .a files? Is it better to install Windows SDK and just forget about those .a files?
Both of these files in this particular case are called "import libraries". Import libraries are basically a file containing a list of valid functions, so that when you link your exe, the linker knows that those functions will exist in some particular DLL. So when you link to wsock32.lib or ws2_32.lib, the linker now knows that these functions will exist in wsock32.dll and ws2_32.dll. Thus, it will not complain. Now, the .lib import library format is Microsoft's format. GCC/unix/linux/mingw/cygwin etc. have a different format, and the extension for that format is .a. Now, cygwin/mingw etc. provide a ws2_32.a so that when using cygwin/mingw/gcc, the linker can read the import library in the correct format. cygwin/mingw/gcc will simply not understand the .lib. Microsoft provides the .lib files in their SDK, but I am not sure how this will help in this case. (Though the SDK is definitely useful, because it provides lots of header files and DLLs for other useful things you might need, but the import libraries are useless, because gcc/mingw/cygwin will not understand them; unless you use a converter tool, like the one mentioned in your duplicate question).
3) Is it possible to use #pragma comment(lib, "libws2_32.a") to link .a files? I've tried but didn't get success results.
No, the #pragma linking comments are an MSVC specific (ugly IMO) extension. Use the linker options in the menus.
eclipse, Cygwin
propeties -> C/C++ Build -> Settings -> Cygwin C Linker
Command line pattern
add to -lws2_32
ex)${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS} -lws2_32

C++ include libraries

Ok, so it's been a while, and i'm having problems with #includes
So I'm doing
#include "someheader.h"
but it's giving me
fatal error: someheader.h: No such file or directory
It's a system wide library I guess you could say.
I'm running arch linux and I installed the library from the repo, and I think the .h files are in /usr/include.
I could just copy all the header files into the folder my code is in but that would be a hack.
What is the "right" way to do this?
Edit: I wasn't correct by saying the .h files were in /usr/include, what I meant was that the library folder was in there
So, Emile Cormier's answer worked to a certain extent.
The problem now is that there are some include in the header file and it seems from the methods I'm trying to access that those includes are not happening
it's giving my the error
undefined reference to Namespace::Class::method()
Edit:
Ok so the final answer is:
#include <library_name/someheader.h>
And compile with
g++ code.cpp -llibrary_name
Sometimes, header files for a library are installed in /usr/include/library_name, so you have to include like this:
#include <library_name/someheader.h>
Use your file manager (or console commands) to locate the header file on your system and see if you should prefix the header's filename with a directory name.
The undefined reference error you're getting is a linker error. You're getting this error because you're not linking in libsynaptics along with your program, thus the linker cannot find the "implementation" of the libsynaptics functions you're using.
If you're compiling from the command-line with GCC, you must add the -lsynaptics option to link in the libsynaptics library. If you're using an IDE, you must find the place where you can specify libraries to link to and add synaptics. If you're using a makefile, you have to modify your list of linker flags so that it adds -lsynaptics.
Also the -L <path_to_library> flag for the search path needs to be added, so the linker can find the library, unless it's installed in one of the standard linker search paths.
See this tutorial on linking to libraries with GCC.
You'd use #include <someheader.h> for header files in system locations.
#include "someheader.h" would try to include the file someheader.h in the directory of your .c file.
In addition to including the header file, you also need to link in the library, which is done with the -l argument:
g++ -Wall youprogram.cpp -lname_of_library
Not doing so is the reason for the "undefined reference .. " linker errors.
The quick fix is to do use:
#include <someheader.h>
assuming that someheader.h is in the standard include locations (to find it use the command locate someheader.h in a shell. If it is in /usr/include it is in a standard location. If it is in a subdirectory of /usr/include you only need to add the part of the directory up to /usr/include in the #include directive (e.g. #include <fancy_lib/someheader.h>)
However, this is only half of the story. You also will need to set up your build system in a way that locates the given library and adds its include path (the path under which it's header files are stored) to the compiler command (for gcc that is -I/path/to/header). That way you can also build with different versions by configuring them in your build system. If the library is not header-only you will also have to add it to the linker dependencies. How this is achieved in your build system is best found out by consulting its documentation.

Problems including jsonCpp headers

I'm trying to implement the jsoncpp libraries in my C++ code, I wrote a simple piece of code just to try it out, and it's not even compiling.
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#ifndef json_included
#define json_included
#include "jsoncpp\include\json\json.h"
#endif
//#include "json\jsonC\json.h"
int main(int argc, char **argv)
{
std::string example = "{\"array\":[\"item1\", \"item2\"], \"not an array\":\"asdf\"}";
Json::Value value;
Json::Reader reader;
bool parsed = reader.parse(example, value, false);
std::cout << parsed;
return 0;
}
The errors i'm getting are:
undefined reference to `Json::Reader::parse(std::string const&, Json::Value&, bool)'
undefined reference to `Json::Reader::Reader()'
undefined reference to `Json::Value::~Value()'
undefined reference to `Json::Value::Value(Json::ValueType)'
I'm a bit new to C++, is there something I'm missing in the include statement? Or does jsonCpp need something extra?
Thank you for your time!
Your code is compiling, but it is not linking. You forgot to provide the JSON shared library files to your linker (or, on newer versions, to add the amalgamated jsoncpp.cpp to your project).
Without knowing more about your development environment, it's hard to give you more specific instructions.
BTW, you're writing C++; use C++ headers like cstdio, not stdio.h, please. You also failed to include C++ string and got lucky that it "worked" through some JSON header including it for you.
"Undefined reference" sounds like a linker problem. Does jsoncpp come with a library that you need to link to, such as a .so, .a, .lib or .dll file?
According to the jsoncpp README, the library must first be built using scons. Presumably this will then output a library file such as a .so, .a, .lib or .dll file. You must then follow your compiler's rule for linking against such a library (e.g. add it to the end of the command line when compiling, or add it to the "additional libraries" field in the project config in your IDE).
In my case (using CodeBlocks IDE on Ubuntu) the problem was that I needed to add the json.cpp file (generated with python amalgamate.py from within the jsoncpp project) to my build targets.
In other words, I added a -c jsoncpp.cpp option to my g++ compile statement.
You need to link to the json libraries, e.g. using -ljson_linux-gcc-4.4.3_libmt
You can find the exact library name by looking in the library directory, e.g. /usr/lib
If you're using Visual Studio, add the .lib file to Project Properties, Linker, Input, Additional Dependencies and specify the path in Project Properties, Linker, General, Additional Library Directories
Two potential issues:
There is a bug in some versions of the jsoncpp library code where amalgated needs to become amalgamation for the linking to work correctly.
As the other answers suggested, #include
After you compile jsoncpp you can find the libraries in the folder libs/ . For convenience you can put it in /usr/lib and then link it at run time by passing -llibjson_linux-gcc-4.4.3_libmt as an argument to g++.
I have renamed libjson_linux-gcc-4.4.3_libmt.so to libjson.so and can link it by specifying -ljson.

How do I resolve LNK1104 error with Boost Filesystem Library in MSCV?

I am having trouble getting my project to link to the Boost (version 1.37.0) Filesystem lib file in Microsoft Visual C++ 2008 Express Edition. The Filesystem library is not a header-only library. I have been following the Getting Started on Windows guide posted on the official boost web page. Here are the steps I have taken:
I used bjam to build the complete set of lib files using:
bjam --build-dir="C:\Program Files\boost\build-boost" --toolset=msvc --build-type=complete
I copied the /libs directory (located in C:\Program Files\boost\build-boost\boost\bin.v2) to C:\Program Files\boost\boost_1_37_0\libs.
In Visual C++, under Project > Properties > Additional Library Directories I added these paths:
C:\Program Files\boost\boost_1_37_0\libs
C:\Program Files\boost\boost_1_37_0\libs\filesystem\build\msvc-9.0express\debug\link-static\threading-multi
I added the second one out of desperation. It is the exact directory where libboost_system-vc90-mt-gd-1_37.lib resides.
In Configuration Properties > C/C++ > General > Additional Include Directories I added the following path:
C:\Program Files\boost\boost_1_37_0
Then, to put the icing on the cake, under Tools > Options VC++ Directories > Library files, I added the same directories mentioned in step 3.
Despite all this, when I build my project I get the following error:
fatal error LNK1104: cannot open file 'libboost_system-vc90-mt-gd-1_37.lib'
Additionally, here is the code that I am attempting to compile as well as a screen shot of the aformentioned directory where the (assumedly correct) lib file resides:
#include "boost/filesystem.hpp" // includes all needed Boost.Filesystem declarations
#include <iostream> // for std::cout
using boost::filesystem; // for ease of tutorial presentation;
// a namespace alias is preferred practice in real code
using namespace std;
int main()
{
cout << "Hello, world!" << endl;
return 0;
}
Ferruccio's answer contains most of the insight. However, Pukku made me realize my mistake. I am posting my own answer to give a full explanation. As Ferruccio explained, Filesystem relies on two libraries. For me, these are:
libboost_system-vc90-mt-gd-1_37.lib
libboost_filesystem-vc90-mt-gd-1_37.lib
I must not have noticed that when I supplied the directory for libboost_filesystem-vc90-mt-gd-1_37.lib, the error output changed from
fatal error LNK1104: cannot open file 'libboost_filesystem-vc90-mt-gd-1_37.lib'
to
fatal error LNK1104: cannot open file 'libboost_system-vc90-mt-gd-1_37.lib'
Causing me to think that the error was persisting. This lead me to post some rather inaccurate information. Also, after reading that Filesystem requires two libraries, I now see the significance of the keyword stage for the bjam command. Supplying
bjam --build-dir="C:\Program Files\boost\build-boost" --toolset=msvc --build-type=complete stage
Causes bjam to place an additional directory, aptly named stage, in the boost_1_37_0 directory. This folder contains a folder named /lib, which has copies of all of the lib files in one place. This is convenient for Visual C++ because you can supply it with this single directory and it will take care of all of the dependencies.
boost::filesystem is dependent on boost::system, so you need both paths.
Part of the problem is you're using the boost libs out of the build directories instead of the install directory (the boost build process should create both). The install/lib directory has all the libs so you only need to specify one path.
The boost build process builds each library in its own directory. At the end it copies all those .lib files into one common lib directory.
Since you didn't specify an install directory as part of your build command (with --prefix=...), I believe the default is C:\Boost. Check to see if that directory is there and if so use C:\boost\include\ boost-1_37 for your include path and C:\boost\lib for your library path.
Last answer is right.
But you should find boost config file $BOOST\config\user.hpp and
uncomment this directive #define BOOST_ALL_DYN_LINK.
Now it begin use dynamic link with boost and it should works.
I think the real original problem is related to the default boost build process on windows which expects static linking of a library which will have a name beginning libboost_sytem<etc..>. The macro you need is
#define BOOST_SYSTEM_DYN_LINK
which makes ensures that the Boost.System library is dynamically linked. The dynamic library name is boost_system<etc...> as apposed the the static library libboost_sytem<etc...>
The bjam command line should have built all versions of all libraries. Still, when you build with
bjam --build-dir="C:\Program Files\boost\build-boost" --toolset=msvc --build-type=complete stage
(note the stage at the end) all libraries are copied to a common libs/ folder, so that MSVC's autolinking feature works when you only add this libs/ folder to your library path.
I do not know if bjam without stage still copies all those files to a single folder. If not, execute such a stage build to do this. If they are, well, sorry, configuration seems correct, maybe a minor typing error somewhere?
The error you have posted complains about file libboost_system-vc90-mt-gd-1_37.lib, but in the directory you have only libboost_filesystem-vc90-mt-gd-1_37.lib, right?
Look for libboost_system-vc90-mt-gd-1_37.lib. If you find it, add the corresponding directory to the library search path. If you don't find it, see if you have boost_system-vc90-mt-gd-1_37.lib instead (like I do), and try copying that to the desired filename.
I had this same problem, what you need to do is add the "lib" directory under the top level boost folder to the library path in Visual C++.
This most definitely solved the issue for me.