I have a Synology DS212j NAS (cpu Feroceon 88FR131 rev 1 (v5l)) with the optware ipkg installed. I am trying to build mongo-nonx86 on it.
"scons all" gives me the following messages:
scons: Reading SConscript files ...
scons version: 2.0.1
python version: 2 5 6 'final' 0
Checking whether the C++ compiler worksyes
Checking for C library stdc++... no
can't find stdc++ library which is needed
I have the stdc++ library installed, I also have ssl installed. My underlying question is how can I get scons to tell me more about what is really missing, where it is looking, how it is looking etc. I have so far found no options which generate any more useful diagnostic output?
Obviously a ready-made solution for getting mongodb working on this great little box would be even more welcome :-)
Well even if you do have it installed, it doesn't seem to think so, here is what I would try to do, install libssl-dev, then try to install the dev package for libstdc++, which is: libstdc++-dev.
Then see if you can compile it.
Related
I'm trying to compile some C code against a 32-bit DLL file that was provided to me. However, I get the following errors from ld (edited for conciseness) using the MSYS2 MinGW-32 environment:
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.dll when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.dll when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: skipping incompatible /<some_path>/mtipli.lib when searching for -lmtipli
/usr/x86_64-pc-msys/bin/ld: cannot find -lmtipli
The last time I got these types of error messages was when I was trying to use a 32-bit library in a 64-bit project. But this time I am as sure as I can be that my compiler is 32-bit.
Does anyone know if there's a way I can get more information so that I can troubleshoot this? I tried using -Wl,--verbose, but ld's verbose messages didn't have anything helpful in them.
More details:
I actually have three incarnations of MinGW on my computer. The first is the basic 32-bit MinGW compiler that I installed using mingw-get several years ago. I later installed the MSYS2 environment, which came with a 32-bit and a 64-bit MinGW. In other words, I have two 32-bit version of MinGW.
I am forced to use the MSYS2 version of the 32-bit MinGW for my project because the basic one doesn't have some headers/libs that I depend on (i.e. stuff I need in addition to the mtipll.dll file shown above). However, if I make a minimal project using only mtipll.dll, the basic MinGW is actually able to compile it, but the MSYS2 MinGW gives me this same error. I am so confused with all these MinGWs floating around!!!
I think I found the explanation, though I don't have a solution yet.
By using objdump, I discovered that the mtipli.dll has file format pe-i386, and so do any executables that I've compiled with the basic MinGW-32. However, all code compiled with the MSYS2 version of MinGW-32 have file format pe-x86-64.
I will ask about this in a new Stack Overflow question and post the link in the comments.
I'm trying to build a shared library to use on a raspberry pi (model 3B) using lazarus. After some puzzling I found out that my original library didn't work properly so I switched to a very simple library using this example.
But even this simple library doesn't compile properly to be used. When I try to open the library in another lazarus project it gives me the error:
< libName >: cannot open shared object file: No such file or directory
After some research I found the following diagnostics I could run. The file and ldd command in the compile library:
$file ./libname.so gives:
./libname.so: ELF 32-bit LSB shared object, ARM, EABI5 verion 1 (SYSV), dynamically linked, not stripped
$ldd ./libname.so
not a dynamic executable
I have searched for similar cases and from found that others had this problem when they tried to use libraries compile for a different platform/architecture. I already set the project>project options>compiler options>target platform to OS:= linux and Target CPU family: arm.
The system I am using (using $uname -a):
Linux raspberrypi 4.4.13-V7+ #894 SMP Mon Jun 13 13:13:27 BST 2016 armv7l GNU/Linux
with distro: Raspbian GNU/linux 8.0 (jessie)
Lazarus version: 1.2.4+dfsg2-1
FPC version: 2.6.4 arm-linux-gtk2
At this point I am not sure what is wrong and why this library isn't working. I can find very little information on this problem (on the aspberry platform and using lazarus) Any suggestions what I could try to make it work, compile it different or do some more diagnostics?
Found the solution. As Marco proposed above: Add initc to the uses part. It seems that if you try to make a library it has to include initc, cmem or LCL to the uses section because the library has to do some memory management for which it needs one of these units.
However this resulted in another error when trying to load the library:
"Undefined symbol: TC_SYSTEM_ISLIBRARY"
This seems to be a raspberry specific problem, compilers on other systems do not give this error. More information can be found HERE.
Eventually solved this by install fpc 3.0.0 compiler on the raspberry pi, compiled it and the library can be loaded properly (but still needs one of the above units).
I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.
I know this issue already discussed (include there), and no one time. But, unfortunately, I cannot solve this problem.
So, I have OS X Lion, i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1, and I try to build gcc-4.7.0.
First of all, I've already built this compiler on Debian GNU/Linux, so I was sure any problems will not be...
So, I read this GCC manual and I did all exactly as described:
cd gcc-4.7.0
./contrib/download_prerequisites
cd ..
mkdir gcc_build
cd gcc_build
/Users/dshevchenko/Downloads/gcc-4.7.0/configure --prefix=/Users/dshevchenko/Tools/GCC
make
So, MPC, MPFR and GMP was successfully downloaded, and ./configure was OK. But after few minutes after make I get this error:
checking for suffix of object files... configure: error:
in `/Users/dshevchenko/Downloads/gcc_build/x86_64-apple-darwin11.4.0/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
As I understand this can't be due error of dynamic linking with MPFR, MPC or GMP, because these libs was built inside of GCC source code tree.
In my ~/.bash_profile:
export DYLD_LIBRARY_PATH=/Users/dshevchenko/Tools/GCC/lib
Help me please, I'll be grateful for any advice.
Be sure you have the latest Xcode (4.4 at the time of this writing). There is a bug in the llvm compiler in some versions of Xcode (including 4.1, which I had). For Xcode 4.4, the command line tools must be downloaded from the Xcode preferences.
the follow solution helped me out:
$ export CC="gcc -D_FORTIFY_SOURCE=0”
$ $srcdir/configure ...
$ make
source: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342
I've been wanting to get my hands dirty with Opa, but had been really feeling the lack of a REPL, which is my weapon of choice in coming to terms with a new language. Lo and behold, the Opa Blog mentioned a tool called opatop which appeared to be just that, but it doesn't seem to be included the standard Mac or Ubuntu distributions.
I trekked over to GitHub, grabbed the source, and started building, but I'm getting the same error mentioned here:
+ /opt/local/bin/ocamlopt.opt dynlink.cmxa unix.cmxa str.cmxa nums.cmxa -g threads.cmxa -thread -I +zip zip.cmxa -I +ocamlgraph graph.cmxa -I /opt/local/lib/ocaml/ulex ulexing.cmxa buildinfos.cmxa libbase.cmxa compilerlib.cmxa libtrx.cmxa opacapi.cmxa passlib.cmxa libqmlcompil.cmxa jslang.cmxa ocamllang.cmxa libbsl.cmxa libbsl/bslregister.cmx opalang.cmxa -o libbsl/bslregister.native
File "_none_", line 1, characters 0-1:
Error: Cannot find file dynlink.cmxa
Command exited with code 2.
I know next to nothing about OCaml development, but it looks like other files with the same extension in the relevant library directory are "OCaml native library files". Given that, is this just a library that wasn't included in the OCaml distribution I ended up with? The Mantis bug referenced in the link above makes it look as though there may be conflicting assumptions about build environments at work.
Regardless, can anyone offer any advice?
Thanks!
OCaml isn't built with native dynlink for Lion yet, so dynlink.cmxa doesn't exist under the default install.
The following patch will enable allow you to build it. From within the OCaml src dir, patch -p1 < PATH/TO/PATCH, and reinstall OCaml as appropriate.
This is for OCaml 3.12.1
--- a/configure 2011-07-04 14:15:01.000000000 -0700
+++ b/configure 2011-08-26 10:18:42.000000000 -0700
## -619,9 +619,9 ##
case "$host" in
*-*-cygwin*) natdynlink=true;;
i[3456]86-*-linux*) natdynlink=true;;
x86_64-*-linux*) natdynlink=true;;
- i[3456]86-*-darwin10.*)
+ i[3456]86-*-darwin1[01].*)
if test $arch64 == true; then
natdynlink=true
fi;;
i[3456]86-*-darwin[89]*) natdynlink=true;;
I have investigated Opa build under OS X Lion and have pushed 2 patches on opalang waiting for approval to solve main problems.
So when the patches will be available, this is my steps (as i remember) to make Opa work under Lion :
First, install necessary tools :
Install OS X Lion
Install Xcode 4
Install MacPorts
Install wget (macports)
Install coreutils (macports)
Install md5sha1sum (macports)
(I think that's all...)
Then compile Opa from source :
git clone https://github.com/MLstate/opalang.git
cd opalang
dependencies/installation_helper.sh --prefix ~/Opa
change your PATH in your ~/.profile : export PATH=~/Opa/bin:$PATH
re-source your .bashrc : source ~/.profile
./configure -prefix ~/Opa
make all install
Your new opa compiler should be in ~/Opa/bin :)