I am working on a Linux Redhat server. I am trying to Bootstrap my CMake 3 download files as per How to download, compile, and install CMake on Linux.
I changed 2 lines in the bootstrap file so that I would be using the appropriate GCC/G++ versions:
# Toolchain compiler name table.
cmake_toolchain_Clang_CC='clang'
cmake_toolchain_Clang_CXX='clang++'
# cmake_toolchain_GNU_CC='gcc'
cmake_toolchain_GNU_CC='/inf/projdig/users/{username}/gcc_install/bin/gcc'
#cmake_toolchain_GNU_CXX='g++'
cmake_toolchain_GNU_CXX='/inf/projdig/users/{username}/gcc_install/bin/g++'
cmake_toolchain_PGI_CC='pgcc'
cmake_toolchain_PGI_CXX='pgCC'
cmake_toolchain_PathScale_CC='pathcc'
cmake_toolchain_PathScale_CXX='pathCC'
cmake_toolchain_XL_CC='xlc'
cmake_toolchain_XL_CXX='xlC'
But, it seems like bootstrap is still referencing some compiler-related files in the root directories even though I want it to only reference these:
/inf/projdig/users/{username}/gcc_install/bin/gcc and
/inf/projdig/users/{username}/gcc_install/bin/g++
Please see this error:
What should I change in the Bootstrap file so that nothing in /usr/... is referenced, and only
/inf/projdig/users/{username}/gcc_install/bin/gcc and
/inf/projdig/users/{username}/gcc_install/bin/g++
are referenced?
UPDATE
Okay, I did manage to fix some problems by specifying
-L/{path to correct libstdc++} compiler option.
However, at the very end of the bootstrap script, this line doesn't work:
I can't just fix it by adding a -L compiler option because this does not invoke a compiler. It's invoking CMake. This command above produces the same error (ie. it searches /usr/lib64 for the libraries, which is the path I don't want it to look through). How can I let CMake look at a different path for libraries? What option should I specify after .../cmake ?
Related
I have the following project layout in Code::Blocks 13.12. I'm running as root.
Notice the file dtconfig.h is in the Headers folder.
The file is located in the same directory as the main.cpp file:
However, when I go to build I get the following error:
When I wrap the include in quotes, such as:
#include "dtconfig.h"
It works, but then I have to modify all the other headers to do the same thing. These headers are not something I have written and are part of a source project. So I don't want to go messing around with these files if I don't have to.
Is there anything I need to do/configure in the program to get this to work?
Also, I am running Ubuntu 16.04.1 LTS Mate.
You're not meant to use angle brackets (<dtconfig.h>) for your own project's code, but if you need to make them work without changing every file, then you can pass an option to the compiler telling it to use your dtSearch directory as an include directory.
I don't know whether C::B supports include directories in the GUI, but you can always fall back to passing -Ipath/to/dtSearch to GCC and Clang directly, or /I for MSVC. You can do this where C::B lets you specify additional command line options for the compiler.
I am trying to build SOCI on Windows with a different library suffix using the CMAKE_SHARED_LIBRARY_SUFFIX option, but the script seems to ignore it.
Here is the command I run in a batch file:
cmake^
-G "NMake Makefiles"^
-DCMAKE_BUILD_TYPE=Release^
-DCMAKE_SHARED_LIBRARY_SUFFIX="-vc140-x64-mt.dll"^
..\soci.3.2.3
The documentation does not say anything about the CMAKE_SHARED_LIBRARY_SUFFIX option, but the core/CMakeLists.txt script uses it to define the SOCI_LIB_SUFFIX option, which is reported on the screen when cmake is run. However, its value is always ".dll" instead of "-vc140-x64-mt.dll", so it must be overwritten somewhere I don't know.
Any idea why is this happening and how fix it?
I am trying to compile a section of a library with cmake and make. I am getting the error when I run Make that the include is failing:
/home/user/Sean/PCL/pcl/apps/src/face_detection/openni_face_detection.cpp:9:57: fatal error: pcl/apps/face_detection/openni_frame_source.h: No such file or directory compilation terminated.
I know that with gcc, you can get the compiler to read to you where it looked for the include, but is there a way to accomplish this with make and cmake.
If the Makefile is automatically generated by CMake, you can launch make like this:
> make VERBOSE=1
to interleave the progression on targets with the actual commands make is executing.
From these commands you should be able to extract the current include paths.
You may probably want to take also a look at the include_directories CMake command,
in case some include paths are missing.
I'm cross-compiling a Win32 target on SUSE Linux using mingw32. None of the conventional verbose/debug options provided the #include search path.
This forced my (lazy) hand to manually reproduce the compile operation that ultimately revealed the header search path.
A brief description...
Run the make operation and take note of the compiler, the directory, and the command line it's executing. Yeah, it's messy, but not impossible. Capture the output to a file if headless.
Change into the directory
Execute the compiler with the --help option. Take note of its verbose option.
Run the compile command specifying the verbose option.
Here's what I got...
#include "..." search starts here:
#include <...> search starts here:
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/include
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/compat/include
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/generic
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/filed
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include/c++
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include/c++/x86_64-w64-mingw32
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include/c++/backward
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include-fixed
/usr/x86_64-w64-mingw32/sys-root/mingw/include
End of search list.
Not too bad...
BTW, this is a cmake 3.5.2 configuration.
Trying to run the following:
#include<iostream>
#include<boost/filesystem/operations.hpp>
namespace bfs=boost::filesystem;
int main()
{
bfs::path p("second.cpp");
if(bfs::exists(p))
std::cout<<p.leaf()<<std::endl;
}
I got some errors in cygwin so I decided to try out netbeans, and used the following as a guide. I added all links and the following for filesystem Project -> properties -> Linker ->Libraries -> Add option -> Other -> -lfile_system as noted here. I have run a separate test using #include<boost/any.hpp> so I am not currently doubting that my boost is not installed correclty.
It seems weird to me that it is "file_system", so I also tried "filesystem" but to no avail.
When i hold Ctrl and click on #include<boost/filesystem/operations.hpp> my netbeans brings up my operations.hpp file so it seems okay (linked properly internally that it can "see" what I want it to see).
The solution to installing boost came in the following form:
1 - If you have any path variables that are being used for Visual Studio you should temporarily change the variable during installation. This is a good guide. Once that is done, this is one step completed.
2 - Download and install MinGW. This is a very easy process and you can find the installer files here.
Once you have done these things (if you are in the same situation as me), you will now be able to properly install boost.
Horay!
Using Boost with cygwin step by step
Create a new Project
It is better to take the names given here in this tutorial exactly. Later ask: It does not work, can then be easier to find.
I do not think I need to mention all T:\ must of course be replaced with your drive.
Project Name : Boost-cyg-Test
Now your Project should look like
Open main.cpp
Overwrite the generated code with the following. We want to that, first of all everything works without error.
Therefore, please do not use your own special code.
It is difficult to find a fault. Then told after several ask, to get:
I have used my own code
#include <iostream>
#include <boost/filesystem.hpp>
using namespace std;
using namespace boost::filesystem;
int main()
{
path p("second.cpp");
if (exists(p)) { std::cout<<p.leaf()<<std::endl; }
}
In this section we assume that "boost" is already compiled.
goto Tools -> Options
Your C++ Code Assistance options should look something like this.
If this is not so, we should let Netbeans create that for us.
Add New Tool Collection
After we have completed this dialog with OK, we should find the settings shown above. ( C++ Code Assistance options).
Copy all libs into the right place
Let's create a new folder 'boost'.
With a search tool, search in your compiled Boost folder for *.a
My Boost is compiled with the shared option so we find :
For our short App. we need only 2 files.
libboost_filesystem-gcc45-mt-d-1_53.dll.a
libboost_system-gcc45-mt-d-1_53.dll.a
But if we're at it to copy two files, we can copy all files.
So mark all found .a files and copy them into the directory just created
T:\cygwin\lib\boost .
Now we do the same with our .dll files.
Mark all .dll files and copy it in your ?:\cygwin\bin directory.
If you only have compiled static librarys, you can skip this point.
Now it's time to modify our project settings.
As you can see i put my source Boost folder into cygwin
and
As we have already noted above, we need two .a files.
with Add Library navigate to T:\cygwin\lib\boost and select
libboost_filesystem-gcc45-mt-d-1_53.dll.a
libboost_system-gcc45-mt-d-1_53.dll.a
Now you'll notice that this name was shortened by netbeans to:
boost_filesystem-gcc45-mt-d-1_53.dll
boost_system-gcc45-mt-d-1_53.dll
This is somewhat confusing. It looks as if a .dll is standing here. But it is really a .a file.
Set a breakpoint in main.cpp. Now we start debug.
I have marked the important part, the two libs, with an arrow.
All libs are found and after make has finished, stops at the breakpoint.
The output:
Build Boost for Cygwin
For all who want to create boost with shared library itself.
Download boost_1_53_0.zip
Create a folder in your ?:\cygwin directory.
boost_1_53_0
Extract the zip file into that directory.
It should look like:
open a cmd window, cd to boost_1_53_0 directory.
To have a clean build we need a PATH that have only the cygwin home and bin.
In the cmd type.
SET PATH=T:\cygwin;T:\cygwin\bin
and test the path.
PATH
Type
bootstrap.bat
Type
.\b2 --build-dir=T:\boost-cyg toolset=gcc variant=debug link=shared runtime-link=shared
After some time the build is finished.
Now you have the same environment that we have used in the tutorial.
If you get a Error : gcc not found
copy (not rename) in ?:\cygwin\bin folder, for example : (names may differ).
i686-pc-cygwin-gcc-4.5.3.exe to gcc.exe
and
i686-pc-cygwin-g++-4.exe to g++.exe
Hope it helps you.
Could you paste the error you get when compiling ?
I am not used to compile programs in a Windows environment, but I think as Jesse Good suggested in a comment that you have a linker error.
You may solve it by using -lboost_filesystem instead of lfile_system.
To find out how your libs are called, you get the name of your lib (on my unix environment I have libboost_filesystem.so), strip the "lib" prefix and the ".so" or ".a" suffix (must be different in a Windows environment).
if your boost installation is correct and you are sure about it then for Unable to resolve identifier try Code Assistance->Reparse Project from context menu of the project. It tries to recover broken code model by reparsing project from scratch. if that didn't workout try closing IDE and removing code model cache.
p.s. do you have compilation errors?
I need to build the log4cxx library on a SuSE linux system where I am not root. The package manager, zypper, apparently does not know about log4cxx.
I download log4cxx and try to build with autotools
./configure
checking for APR... no
configure: error: APR could not be located. Please use the --with-apr option.
I then search for libapr:
find / -name libapr*
/usr/share/doc/packages/libapr-util1
/usr/share/doc/packages/libapr1
/usr/lib64/libaprutil-1.so.0.3.12
/usr/lib64/libapr-1.so.0.4.5
/usr/lib64/libaprutil-1.so.0
/usr/lib64/libapr-1.so.0
So I try
./configure --with-apr=/usr/lib64/libapr-1.so.0
configure: error: the --with-apr parameter is incorrect. It must specify an install prefix, a build directory, or an apr-config file.
The same for --with-apr=/usr/lib64/libapr-1.so.0.4.5 and --with-apr=/usr/lib64/.
Which file does ./configure look for? What does --with-apr expect? Is one of the two *.so.* files the needed library?
You'll probably want to install libapr1-devel so that you can compile against it. Then try re-running ./configure.
I ran into the same issue, I think you're using the source code off of appache's site which I beleive is outdated. This issue has been fixed in the SVN trunk several years ago (lolol, I guess right around the time this question was asked).
Just pull the svn trunk's source and compile it:
svn checkout http://svn.apache.org/repos/asf/incubator/log4cxx/trunk apache-log4cxx
./autogen.sh
./configure
make
make check
sudo make install
On software.opensuse.org someone has packages built for recent versions of openSUSE as well as SLE at liblog4cxx10. Maybe that'll work for you instead of building your own.
MichaelGoren is right.
There is multiple ".h" file missing.
So you have to add them before launching make.
sed -i '1i#include <string.h>\n' src/main/cpp/inputstreamreader.cpp
sed -i '1i#include <string.h>\n' src/main/cpp/socketoutputstream.cpp
sed -i '1i#include <string.h>\n' src/examples/cpp/console.cpp
sed -i '1i#include <stdio.h>\n' src/examples/cpp/console.cpp
I bumped into the same problem on 3.3.4-5.fc17.x86_64 and resolved it by including the appropriate H files to the CPP files reported by the make utility.
In my case I should run the make utility 3 times each time getting a new error and fixing it by adding the appropriate include H to the reported CPP file.
The main idea is as following:
1) Check by running the man utility, where the function mentioned in the error defined.
For example, man memmove says that it is defined in the string.h header file.
2) Add the appropriate include file to the CPP file.
For example, the make utility complains that inputstreamreader.cpp does not find the memmove function. Open the inputstreamreader.cpp file and add string.h to its header files.
3) Run the make utility until the log4cxx is compiled without errors.