I'm trying to compile zlib from the command line, and I'm getting this message when using -Wall -Wextra -Wconversion (full cross-compile script is below):
Compiler error reporting is too harsh for ./configure (perhaps remove
-Werror).
Here's the configure test that's generating the line:
cat > $test.c << EOF
int foo() { return 0; }
EOF
echo "Checking for obsessive-compulsive compiler options..." >> configure.log
if try $CC -c $CFLAGS $test.c; then
:
else
echo "Compiler error reporting is too harsh for $0 (perhaps remove -Werror)." | tee -a configure.log
leave 1
fi
Its not clear to me what exactly is being judged too harsh (especially since -Werror is not present). I also don't quite understand what the sample program used in the test is doing, so its not clear to me what the criteria is for judging the compiler warnings "too harsh".
What is zlib complaining is too harsh?
#! /bin/sh
export PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH"
export CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
export CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
export LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
export AR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar
export RANLIB=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib
export CFLAGS="-Wall -Wextra -Wconversion --sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdks""
export CXXFLAGS="-Wall -Wextra -Wconversion --sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk""
I had the exact same problem on a newly built machine, and I found the cause was that I didn't actually have the appropriate GNU C compilers installed (reference). Therefore it's complaining that the compiler is too harsh simply because there is no compiler.
Try running:
sudo apt-get install build-essential
and then try running your ./configure again.
My problem was:
cc1: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
Search for details in configure.log.
mine was failing because it tried to use cc (non existent) instead of gcc
is a old question, but i just had this problem compiling zlib 1.2.11 and to bypass this needed to force sudo previous to configure
sudo ./configure --prefix=path
Related
I've been trying to convert a cpp file to wasm without emscripten recently and I've been running with some errors, for example, when I run these commands:
clang++ --target=wasm32 -nostdlib -O3 -o public/main.o -c src/*.cpp
wasm-ld --no-entry --export-all --lto-O3 --allow-undefined --import-memory public/main.o -o public/main.wasm
it gives me this error:
wasm-ld: error: unknown file type public/main.o
Here are the versions of clang and lld that I currently have:
clang version 12.0.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/jp4r5v8pla63qam5w34jvfyfmq8p74am-clang-12.0.1/bin
LLD 12.0.1
Also, I'm running the code on replit
Thank you
Ok, with this commands it works :D
clang++ --target=wasm32 -emit-llvm -c -S -o public/files/main.ll src/main.cpp
llc -march=wasm32 -filetype=obj -o public/files/main.o public/files/main.ll
wasm-ld --no-entry --export-all -o public/main.wasm public/files/main.o
The only thing is that you need to create some new files (main.ll and main.o) but it doesn't matter.
The place where I obtained the solution is here: https://surma.dev/things/c-to-webassembly/index.html
It was really useful
I am working on tesseract engine . Used red hat linux to build both leptonica and tesseract . On running tesseract getting following error.
[tesseract-ocr]$ tesseract address.png out1
Error in pixReadMemTiff: function not present
Error in pixReadMem: tiff: no pix returned
Error in pixaGenerateFontFromString: pix not made
Error in bmfCreate: font pixa not made
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Error in pixReadStreamPng: function not present
Error in pixReadStream: png: no pix returned
Error in pixRead: pix not read
Error during processing.
while searching on the net , i came to find that it is problem with leptonica build . and it is not built properly with ltiff . In fact in config.log which gets generated out of ./configure command . i can see following
configure:12538: checking for TIFFOpen in -ltiff
configure:12564: gcc -o conftest -g -O2 -Wl,-rpath -Wl,/lib64 conftest.c -ltiff -lm
>&5
/bin/ld: cannot find -ltiff
However i see that libtiff is present in the system
[ec2-user#ip-172-31-35-131 lib]$ ldconfig -p | grep libtif
libtiffxx.so.5 (libc6,x86-64) => /lib64/libtiffxx.so.5
libtiff.so.5 (libc6,x86-64) => /lib64/libtiff.so.5
I tried pointing to /lib64 path , as per reference from leptonica site [http://www.leptonica.com/source/README.html][1]
Finally, if you find that the installed programs are unable to link
at runtime to the installed library, which is in /usr/local/lib,
try to run configure in this way:
LDFLAGS="-Wl,-rpath -Wl,/usr/local/lib" ./configure
which causes the compiler to pass those options through to the linker.
changing LDFLAGS to point to /lib64 is also not working LDFLAGS="-Wl,-rpath -Wl,/lib64" ./configure
Any suggestions ?
Try to install
apt-get install -y libtiff5-dev
Then install leptonica from source
git clone https://github.com/DanBloomberg/leptonica.git leptonica
cd leptonica
./autobuild
./configure --with-libtiff
make -j
make install
And reinstall tesseract after that
I recently tried to build my https://github.com/eyalroz/cuda-api-wrappers/ library's examples after switching to another Linux distribution on the same machine. Strangely enough, I encountered a linking issue. The command:
/usr/bin/c++ -Wall -std=c++11 -g CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o -o examples/bin/device_management -rdynamic lib/libcuda-api-wrappers.a -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -ldl -lrt
fails to find the CUDA runtime library, and I get:
CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o: In function `cuda::device::peer_to_peer::get_attribute(cudaDeviceP2PAttr, int, int)':
/home/eyalroz/src/mine/cuda-api-wrappers/src/cuda/api/device.hpp:38: undefined reference to `cudaDeviceGetP2PAttribute'
collect2: error: ld returned 1 exit status
but if I add -L/usr/local/cuda/lib64 it builds fine. This didn't use to happen before; and it doesn't happen on another machine I've checked on, nor does it even happen to other targets using the CUDA runtime in the same CMakeLists.txt (like version_managament).
FindCUDA seems to be finding everything, as the value of ${CUDA_LIBRARIES} is /usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so. And the target lines in CMakeLists.txt are:
add_executable(device_management EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
target_link_libraries(device_management cuda-api-wrappers ${CUDA_LIBRARIES})
as is suggested in answers to other related questions (e.g. here). Why is this happening? Should I "manually" add the -L switch?
Edit: Following #RobertCrovella's suggestion, here are the ld search paths:
$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | tr ':' "\n" | tail -n +3
/usr/local/cuda/lib64/x86_64-linux-gnu/5/
/usr/local/cuda/lib64/x86_64-linux-gnu/
/usr/local/cuda/lib/
/usr/lib/gcc/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/
/usr/x86_64-linux-gnu/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/lib/x86_64-linux-gnu/5/
/lib/x86_64-linux-gnu/
/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/usr/local/cuda/lib64/
/usr/x86_64-linux-gnu/lib/
/usr/lib/
/lib/
/usr/lib/
$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
Notes:
Yes, I know the CMakeLists.txt there is ugly.
TL;DR:
After the FindCUDA invocation, add the lines:
get_filename_component(CUDA_LIBRARY_DIR ${CUDA_CUDART_LIBRARY} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-L${CUDA_LIBRARY_DIR}")
and building should succeed on both systems.
Discussion:
(Paraphrasing #RobertCrovella and myself in the comments:)
OP was expecting, that if the following hold:
FindCUDA succeeds
${CUDA_LIBRARIES} includes a valid full path to either the static or the dynamic CUDA runtime library
the library dependency is indicated using target_link_libraries(relevant_target ${CUDA_LIBRARIES})
... then the CMake-based build he was attempting should succeed on a variety of valid CUDA installations. That is (unfortunately) not the case, since while FindCUDA does locate the CUDA library path, it does not actually make your linker search that path. So a failure should actually be expected. The build had worked on OP's old system due to a "fluke", or rather, due to OP having added the CUDA library directory to the linker's search path, somehow, apriori.
The linking command must be issued with the -L/path/to/cuda/libraries switch, so that the linker knows where to looks for the (unspecified-path) libraries referred to be the CUDA-related -l switches (in OP's case, -lcudart_static).
This answer discusses how to do that in CMake for different kinds of targets. You might also want to have a look at man gcc (the GCC manual page, also available here) regarding the -l and -L options, if you are not familiar with them.
i installed sabayon linux and i tried to install pycuda but i am receiving the following error when i try
su -c "make install"
In file included from src/cpp/cuda.cpp:1:0: src/cpp/cuda.hpp:12:18:
fatal error: cuda.h: No such file or directory compilation terminated.
error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1
I must mention that i can compile with cuda.
The same happens and when i try with
sudo -E sh -c "make install"
My .bashrc is :
# Put your fun stuff here.
export PATH=~/bin:$PATH
export PATH=$PATH:$HOME/Matlab_2010b/bin
export PATH=/opt/cuda/bin:$PATH
export LD_LIBRARY_PATH=/opt/cuda/lib64:$LD_LIBRARY_PATH
export CUDA_ROOT=/opt/cuda/bin
(When i do echo $PATH as user it shows me : /opt/cuda/bin but when i try it as root it doesn't show anything and i had to do export PATH...again in order to show.)
You have CUDA installed in a non-standard path and the PyCUDA installer doesn't know how to find the toolkit headers it needs to compile. As per the installation instructions, you need to do something like this:
python configure.py --cuda-root=/opt/cuda
then
su -c "make install"
this will ensure that the compilation can find the necessary driver API headers to build the support libraries and hardcode all the right paths into the PyCUDA python libraries so that everything works correctly.
I'm attempting to get DBD::MySQL working on Snow Leopard (v10.6.6). The default version of Perl that comes with the OS is v5.10.0. Since I've read that's 64-bit, I went ahead and downloaded and installed a 64-bit version of MySQL (mysql-5.5.8-osx10.6-x86_64).
Installing and setting up MySQL went smoothly, here's my config and version number for reference.
I used CPAN to download DBI and the DBD::MySQL drivers. I then:
Installed DBI
Setup a Makefile.PL
Ran the make command from the command line
The Makefile.PL said it would use the following settings for compiling and testing:
I will use the following settings for compiling and testing:
cflags (mysql_config ) = -I/usr/local/mysql/include -Os -g -fno-common -fno-strict-aliasing -arch x86_64
embedded (mysql_config ) =
libs (mysql_config ) = -L/usr/local/mysql/lib -lmysqlclient -lpthread
mysql_config (guessed ) = mysql_config
nocatchstderr (default ) = 0
nofoundrows (default ) = 0
ssl (guessed ) = 0
testdb (default ) = test
testhost (default ) =
testpassword (User's choice) = r00t!
testsocket (default ) =
testuser (User's choice) = root
To change these settings, see 'perl Makefile.PL --help' and
'perldoc INSTALL'.
Multiple copies of Driver.xst found in: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/ /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level/auto/DBI/ at Makefile.PL line 907
Using DBI 1.616 (for perl 5.010000 on darwin-thread-multi-2level) installed in /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/
Writing Makefile for DBD::mysql
Everything seemed to be going fine, until I tried to run make test :
t/00base....................NOK 2/6# Tried to use 'DBD::mysql'.
# Error: Can't load '/Users/swm/.cpan/build/DBD-mysql-4.018-Pnd2qz/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/swm/.cpan/build/DBD-mysql-4.018-Pnd2qz/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Library not loaded: libmysqlclient.16.dylib
# Referenced from: /Users/swm/.cpan/build/DBD-mysql-4.018-Pnd2qz/blib/arch/auto/DBD/mysql/mysql.bundle
# Reason: image not found at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/DynaLoader.pm line 207.
# at (eval 7) line 2
# Compilation failed in require at (eval 7) line 2.
# BEGIN failed--compilation aborted at (eval 7) line 2.
FAILED--Further testing stopped: Unable to load DBD::mysql
make: *** [test_dynamic] Error 9
It's failing because it can't seem to find the mysql.bundle for DBD. Has anyone come across this problem? Or can point me in the right direction on what to try next? I need DBI/DBD::MySQL for my new job and I'm scrambling to find a solution.
Many thanks in advance.
I got around the "Library not loaded: libmysqlclient.16.dylib" problem by placing a symbolic link in /usr/lib/" to /usr/local/mysql-5.5.8-osx10.6-x86_64/lib/libmysqlclient.16.dylib
I worked around the same or a similar issue. Somehow I could build and test DBD::mysql with cpan but when I tried to use it in a script it said things like
dyld: lazy symbol binding failed: Symbol not found: _mysql_init
Referenced from: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql/mysql.bundle
Expected in: flat namespace
Apparently, it's a 64-bit vs 32-bit issue.
Installing the fink dbd-mysql-pm5100 package made it work though it took kind of a long time. I also removed the cpan-installed version:
sudo rm -rf /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBD/mysql
sudo rm -rf /Library/Perl/5.10.0/darwin-thread-multi-2level/DBD/mysql
sudo rm -rf /Library/Perl/5.10.0/darwin-thread-multi-2level/DBD/mysql.pm
also include in .profile
export VERSIONER_PERL_PREFER_32_BIT=yes;
Besides creating the link the executions of the program with DBI::mysql generated an error, thus including this variable on the environment make it works
I know this is an old post. But I suppose the best solution would be to add the library directory to the DYLD_FALLBACK_LIBRARY_PATH env variable. (reason here: https://stackoverflow.com/a/3172515/119958 )
There is no ldconfig in mac, so just add the path to this env var and rerun the install process for DBD::mysql
Donato-Vianas-MacBook-Pro:Invoicer donato$ cpanm DBD::mysql
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.022.tar.gz ... OK
Configuring DBD-mysql-4.022 ... OK
Building and testing DBD-mysql-4.022 ... FAIL
! Installing DBD::mysql failed. See /Users/donato/.cpanm/build.log for details.
# Failed test 'use DBD::mysql;'
# at t/00base.t line 21.
# Tried to use 'DBD::mysql'.
# Error: Can't load '/Users/donato/.cpanm/work/1359948144.491/DBD-mysql-4.022/blib/arch/auto/DBD/mysql/mysql.bundle' for module DBD::mysql: dlopen(/Users/donato/.cpanm/work/1359948144.491/DBD-mysql-4.022/blib/arch/auto/DBD/mysql/mysql.bundle, 2): Library not loaded: libmysqlclient.18.dylib
Donato-Vianas-MacBook-Pro:Invoicer donato$ export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/mysql/lib/:$DYLD_FALLBACK_LIBRARY_PATH
Donato-Vianas-MacBook-Pro:Invoicer donato$ cpanm DBD::mysql--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/C/CA/CAPTTOFU/DBD-mysql-4.022.tar.gz ... OK
Configuring DBD-mysql-4.022 ... OK
Building and testing DBD-mysql-4.022 ... OK
Successfully installed DBD-mysql-4.022
1 distribution installed
Donato's solution works for install, but the var has to be present at runtime as well or I get the same error. The following fixes this at runtime for shell and _www user:
# For command line use, add following line to ~/.bash_profile:
export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/mysql/lib/:$DYLD_FALLBACK_LIBRARY_PATH
# If Apache needs it, add following line to /etc/apache2/httpd.conf:
# On Lion Server, I put it after <IfDefine MACOSXSERVER>, but shouldn't matter
SetEnv DYLD_FALLBACK_LIBRARY_PATH /usr/local/mysql/lib/:$DYLD_FALLBACK_LIBRARY_PATH
It's somewhat of an aside, but I strongly recommend setting up a separate perl on the machine -- either by fink / macports, or from source -- and leaving the Mac's system perl (and its libraries) alone.
Once I did this on my own Mac, I had very few troubles installing modules thereafter, and I didn't have to worry about accidentally blowing a hole in my OS by breaking the perl that the system uses.
If it were my Mac, I'd install a new perl from source (the Perl source distribution is smart enough to install itself see that it's on a Mac and install itself safely into /usr/local/bin) and the proceed from thee to install DBD::Mysql (and the other modules you require).