Heading
I am trying to use Boost Wave, but I fail to compile it with those samples in boost_1_55_0/lib/wave/samples. The system I am using is Ubuntu 12.04 64-bit
For examples, when I try to compile the quick_start.cpp I use the commend:
c++ -I ~/Documents/boost_1_55_0 quick_start.cpp -o parser \
~/Documents/boost_1_55_0/stage/lib/libboost_wave.a
The libboost_wave.a is what I get from the ./b2 build commend of boost. The compile output is a super long result ending with:
collect2: ld returned 1 exit status
Part of the rest of output looks like(they are so long):
/tmp/ccpBhjhs.o: In function `boost::filesystem::operator!=(boost::filesystem::path
const&, boost::filesystem::path const&)':
quick_start.cpp: (.text._ZN5boost10filesystemneERKNS0_4pathES3_[boost::filesystem::operator!=(boost::filesystem::path const&, boost::filesystem::path const&)]+0x1f): undefined reference to `boost::filesystem::path::compare(boost::filesystem::path const&) const'
/tmp/ccpBhjhs.o: In function `boost::thread_exception::thread_exception(int, char const*)':
I have no clue what happened! Thanks for reading! If you can help me, Please!
p.s. I have built the wave library following the steps on Boost Website. I managed to use the regex library to build the sample e-mail extract program. So I think my wave library is built correctly.
Try the suggestions in this link:
Linking boost::filesystem on Ubuntu 13.04
1) Check that your boost library contains required symbols, you can use something like this: nm -D /usr/lib64/libboost_filesystem.so.1.52.0 | grep detail | c++filt | grep your names
2) Try to change order of linking library, for example put -lboost_bla-bla-bla to the end of command line, and run this command with g++ again, not use make or something, just copy paste command and make experiments with it.
3) And, of course, make sure you have a "libboost_filesystem.XXX" (either a static .a or shared .so library), and make sure it's in your "ld" (link) command.
Related
I've configured and built gpreftools. however, I can't seem to find the generated profile file of my program to display it.
I took the following actions:
Adding the -lprofiler linker flag to my .pro, building the program and the flag is added correctly at the linking stage.
QMAKE_LFLAGS += -lprofiler
Running with:
$ CPUPROFILE=/tmp/prof.out /path/to/executable
Executing:
$ pprof --gv /path/to/MyExe /tmp/prof.out
Then I get the following:
Failed to get profile: curl -s --max-time 90 'http:///pprof/profile?seconds=30' > /home/eslam/pprof/.tmp.MyExe.1509005857.: No such file or directory.
Anyone has a resolve on this?
Check that your program actually links to libprofiler.so. Some OSes (e.g. AFAIK some versions of ubuntu) do not actually add .so if none of it's symbols are actually used. E.g. ldd ./yourprogram should list libprofiler.so. If this does not happen, then you should prepend something like -Wl,--no-as-needed to your linker flags.
LD_PRELOAD method without rebuild
Besides passing -Wl,--no-as-needed,-lprofiler,--as-needed at build time mentioned by Eslam, you can also get it to work without modifying the build by passing the LD_PRELOAD option at runtime as:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libprofiler.so CPUPROFILE=prof.out ./main.out
You can find libprofiler.so easily with locate libprofiler.so.
See also: How can I profile C++ code running on Linux?
Tested in Ubuntu 18.04.
I am trying to cross compile NPM Sqlite3 with sqlcipher support. I am using Ubuntu 16.04 to cross compile for linux armv7 based SOC(system on chip).
So I started with cross-compiling OpenSSL to build sqlcipher for arm. I successfully cross compiled sqlcipher to produce a static library (libsqlcipher.a).
Now I am trying to get the NodeJS side of the project. I need sqlite with sqlcipher support, compiled for arm. I am using SOC SDK to built till now.
I am using node v4.6.1 and npm v2.15.9 to cross compile. I made sure I have the same version installed on Ubuntu as the SOC.
The command I use to cross compile is as follows :
npm install sqlite3 --target_arch=arm --enable-static=yes --build-from-source --sqlite_libname=sqlcipher -fPIC --sqlite=home/onkar/Library/sqlcipher-master/.libs --verbose
I exported the location of the libsqlcipher.a to LDFLAGS. I get the following error when I try to cross compile. Can someone help me with this error?
/home/linuximage/sdk/sysroots/x86_64-angstromsdk-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/5.2.1/real-ld: error: /home/Library/sqlcipher-master/.libs/libsqlcipher.a(sqlite3.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
collect2: error: ld returned 1 exit status
node_sqlite3.target.mk:129: recipe for target 'Release/obj.target/node_sqlite3.node' failed
make: *** [Release/obj.target/node_sqlite3.node] Error 1
Please let me know if you require any additional information, I would be more than happy to provide you with the same.
Thanks,
Onkar
In the first instance, you should check if the -fPIC (position independent code) flag was correctly applied when the libsqlcipher.a file was originally created.
In your output above, it looks like the linker is using the file at:
/home/Library/sqlcipher-master/.libs/libsqlcipher.a
Run the command
objdump -r /home/Library/sqlcipher-master/.libs/libsqlcipher.a | more
... and check for a line close to the start of the output beginning with the text
RELOCATION RECORDS FOR
If you see this line, then the library doesn't contain position independent code.
I start saying that i am a newbie in programming and then i am not sure i will be able to explain well my problem.
I had some c++ code i wrote, this code are loaded and used by some R functions.
To compile the code i used the following:
R CMD SHLIB MyCode.cpp
and i loaded the library in R with
dyn.load("MyCOde.so")
Sometimes i built also an R package and i was able to load it into R.
If i do all these stuff on a Mac with mountain lion everything work fine, but now that i switched to mavericks, i have some problems. The R CMD SHLIB MyCode.cpp command works but when i used dyn.load("MyCOde.so") i get the following text:
Errore in dyn.load(paste(dir_function, "MyCOde.so", sep = "")) :
unable to load shared object 'MyCOde.so':
dlopen(MyCOde.so, 6): Symbol not found: __ZNSt8ios_base4InitC1Ev
Referenced from: MyCOde.so
Expected in: flat namespace
in MyCOde.so
Moreover if i try to load the package in R, i get the following
ld: warning: directory not found for option '-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
ld: library not found for -lquadmath
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [MyCode.so] Error 1
Can someone helps me?
Based on the helpful website of:
thecoatlessprofessor
Type this into your terminal shell:
curl -O http://r.research.att.com/libs/gfortran-4.8.2-darwin13.tar.bz2
sudo tar fvxz gfortran-4.8.2-darwin13.tar.bz2 -C /
This will create what you need to resume compiling as before.
Since it starts to work I can publish the answer for such a cases.
When you change the compiler and standard libraries - please note that different libraries have different implementation and different standard support. Changing the basement of your system might require total rebuild of your system with the new C++ standard library.
Your libraries are not the exception. So if have the errors in your linker like this:
warning: directory not found for option
'-L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2'
apply next algorithm:
Check whether the directory /usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 still exists. I bet it is not.
Check if you still have the libstdc++ from the missed compiler? Usually if you upgrade the same compiler and the C++ standard library ABI does not change everything should continue to work. If the ABI changed or you switch standard C++ library and compiler - you face the massive system rebuild.
Recompile your library and apps with the new C++ standard library and compiler.
I am trying to build wxHaskell for wxWidgets 3.0. I used the latest git version of wxHaskell from https://github.com/wxHaskell/wxHaskell.
I tried to follow install.txt in wxHaskell-master.zip, what I did so far is:
cd wxdirect
cabal install
cd ../wxc
cabal install
wxc won't compile because its Setup.hs requires wxWidgets 2.9. I replaced
let wxRequiredVersion = "2.9"
with
let wxRequiredVersion = "3.0"
and then did:
cabal install --extra-lib-dirs=/usr/local/lib
All compilation went OK, but I got a few link errors in the end. The hardest one to solve is the following:
dist\build\src\cpp\eljlog.o:eljlog.cpp:(.rdata$_ZTV6ELJLog[vtable for ELJLog]+0x20): undefined reference to `wxLog::DoLog(unsigned long, char const*, long)'
The corresponding source code is in wxc/src/cpp/eljlog.cpp:
class ELJLog : public wxLog
{
private:
TLogFunc func;
void* EiffelObject;
protected:
virtual void DoLog(wxLogLevel level, const wxChar *szString, time_t t)
{
wxString s(szString);
func (EiffelObject, (int)level, (void*)&s , (int)t);
}
....
I couldn't figure out what caused this error and how to fix it. I did some search about this vtable issue, and some suggested that this is caused by declaring a virtual function in a child class without defining it. Others suggested that it's the order that object files are given on the g++ command line. But neither seems to be the case here.
I tried removing the function ELJLog::DoLog function or commenting out the virtual keyword. Strangely, there is always a link error/errors saying something about vtable for ELJLog, and refers to wxLog::DoLog, even when there is no occurrence of DoLog.
Also, as a side note, wxLog::DoLog seems to be missing in the wxWidgets 3.0 documentation. I am not sure whether this function is deprecated or not. But still, it's causing errors for legacy derived classes in a way that I can't understand.
Any ideas what's going on here?
--- EDIT2 ---
If I comment out the function in question
virtual void DoLog(wxLogLevel level, const wxChar *szString, time_t t) ...
I got different link errors as follows:
dist\build\src\cpp\eljlog.o:eljlog.cpp:(.rdata$_ZTV6ELJLog[vtable for ELJLog]+0x
20): undefined reference to `wxLog::DoLog(unsigned long, char const*, long)'
dist\build\src\cpp\eljlog.o:eljlog.cpp:(.rdata$_ZTV6ELJLog[vtable for ELJLog]+0x
24): undefined reference to `wxLog::DoLog(unsigned long, wchar_t const*, long)'
collect2: ld returned 1 exit status
--- EDIT ---
I worked on this under mingw32 from mingw.org. I built wxWidgets 3.0.0 stable release from source, and the stpes I did were as follows:
per http://mingw.5.n7.nabble.com/win32api-version-4-td32288.html :
edit line 2217 of /c/mingw/{,mingw32/}include/commctrl.h to read
#define TV_DISPINFO NMTVDISPINFO
instead of
#define TV_DISPINFO __AW(NMTVDISPINFO)
The above was needed to fix a MinGW32 4.8.1-4 issue. Then,
./configure --enable-stl --disable-shared
make
make install
./configure --enable-stl
make
make install
mv /usr/local/lib/wx*.dll /c/mingw/bin/
It seems a definition for
virtual void DoLog(wxLogLevel level, const char *szString, time_t t)
is missing in the subclass ELJLog of wxLog. Adding the following copy of DoLog differing in the interface only solved the problem:
virtual void DoLog(wxLogLevel level, const char *szString, time_t t)
{
wxString s(szString);
func (EiffelObject, (int)level, (void*)&s , (int)t);
}
Seeing your build steps now, I don't understand why do you build both the static and shared versions of the libraries. Do you really need both of them? Usually just one (typically shared/DLL when building extensions) is enough. If you do need both, you really should build them in different build directories to avoid weird build issues due to having the files from the old build. So I'd advise to do the following:
Entirely delete your existing sources.
Get them anew (and apply the MinGW fix).
Create build_shared subdirectory and run ../configure && make && make install there.
If this is not enough, i.e. if you really need the static libraries too, create build_static subdirectory of the top level sources directory and run ../configure --disable-shared && make && make install there.
If anything goes wrong in the future, you can always just do rm -rf build_whatever and create a new build directory and rebuild there (cd build_whatever && make -s clean works also, but rm -rf is more satisfying).
Original answer below: it can still be useful to somebody else but it doesn't seem to apply in your case.
One possibility is that you built wxWidgets without 2.8 compatibility. It is on by default, so check that you didn't use --disable-compat28 configure option (I guess this is under Unix?).
If wxLog::DoLog() is actually there in the library (you could use nm or objdump to check this), then I'd check for the use of obsolete g++ #pragma interface and #pragma implementation pragmas as they can result in such breakage IME. If you do find them anywhere, just remove them completely (but remove both of them, otherwise you are certain to have link errors).
Like previously referred here, ___sincos_stret can not be found when compiling a project that uses this symbol using the Xcode5 command line tools.
In the above referenced thread a solution is posted for IOS targets (passing -miphoneos-version-min=5.0 to the compiler), is there a solution for desktop (x64) targets?
It for example happens for me when trying to compile polycode.
Edit 2:
Strangely, after compiling the libraries referenced in the previous error manually, the error now happens to be located in lto.o, which is an internal llvm header itself...
undef: ___sincos_stret
Undefined symbols for architecture x86_64:
"___sincos_stret", referenced from:
_mdct_init in lto.o
_dradfg in lto.o
I'm running OSX 10.9 DP with Xcode 5. This is the link step.
stret is Apple-speak for "returns a structure". ___sincos_stret is an LLVM optimisation — if you write code that calls sin(n) and then cos(n) and uses both results then the compiler will make one call to the structure-returning sincos method, receiving a structure with both things in it. It's faster to work out both at once rather than individually if the operand is the same.
On a superficial browsing I can't see a sin or cos in initInterTab2D but I expect something is being inlined.
While poking around I tried:
cd /Applications/Xcode.app/Contents/Developer/Platforms
grep -lr ___sincos_stret *
Via that and using nm on likely results, I found the ___sincos_stret function is exposed in both iOS since 7.0 and OS X since 10.9 as part of their libsystem_m.dylibs. E.g. if your Xcode is installed in the default place, try:
nm /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/lib/system/libsystem_m.dylib | grep sincos
And/or:
nm /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/system/libsystem_m.dylib | grep sincos
You'll see the symbol in either of those. So the correct solution would be to set an older deployment target in Xcode, or do the equivalent in your makefile.
You want -mmacosx-version-min=10.8 (or whatever your targeted OS version is).
It seems like un- and reinstalling Xcode5 DP and the OSX 10.9 command line tools solved the problem. I guess there was a problem with updating from the previous versions.
Open the following file in a text editor
/opt/local/etc/macports/macports.conf
and add there a lines like
# MACOSX_DEPLOYMENT_TARGET - osx version to be compatible with earlier OSX version.
macosx_deployment_target 10.8
MACOSX_DEPLOYMENT_TARGET 10.8