Perl compile, libgdbm incompatibility - linux

I'm trying to compile Perl (any version) on a Linux RHEL 6.8 system. Whether I compile manually or use perlbrew, the result is the same. It dies when encountering the libgdbm.so.2.0.0 file.
Here is the tail of the transcript:
Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:
#include <stdio.h>
int main() { printf("Ok\n"); return(0); }
I used the command:
cc -o try -O2 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -fstack-protector -L/usr/local/lib try.c -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lut
il -lc
./try
and I got the following output:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../libgdbm.so when searching for -lgdbm
/usr/bin/ld: skipping incompatible /usr/lib/libgdbm.so when searching for -lgdbm
/usr/bin/ld: cannot find -lgdbm
collect2: ld returned 1 exit status
I can't compile the test program.
(The supplied flags or libraries might be incorrect.)
You have a BIG problem. Shall I abort Configure [y]
Ok. Stopping Configure.
Any ideas? I don't think that version of libgdbm is old.

This is the first that I noticed that my list of libraries includes both 64 bit and 32 (unmarked) versions. I eliminated the non-64 ones and now I'm compiling. Not sure if that is all of my issues, but that is it for this particular detail. – Cliff Warren

Related

HEXAGON Halide Tools 2.3: /usr/bin/ld: cannot find -lc++abi

I did not get response from Qualcomm forum so I decided to post here. When I was trying to run examples of Halide for Hexagon by running make run as written in the document. Then I got the following issue. The -lc++abi is missing.
clang++ -std=c++11 -I /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/include -stdlib=libc++ -O3 -g -fno-rtti -rdynamic conv3x3_generator.cpp /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/lib/libHalide.a /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/tools/GenGen.cpp -o /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/Examples/build/offload/hexagon_benchmarks/bin/conv3x3.generator -lz -lrt -ldl -lpthread -lm
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked the /usr/lib and find. So it should be there?
./x86_64-linux-gnu/libc++abi.so.1.0
./x86_64-linux-gnu/libc++abi.so.1
./llvm-10/lib/libc++abi.so.1.0
./llvm-10/lib/libc++abi.so.1
Did I miss anything or make anything stupid? Thanks!
ld is your system's host linker -- that's GNU BFD ld. clang++ must be in your PATH but it's the host clang++ and not the hexagon-clang++ that would be with Halide/Hexagon tools.
I contacted the person from Qualcomm. I am not supposed to use either /usr/bin/clang++ nor hexagon-clang++. I downloaded clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz from https://releases.llvm.org/7.0.1/. You should use clang++ under the bin folder after you extract it. Now it works for me.

GLFW linking, undefined reference to init

So i am trying to compile a simple GLFW window app, and i ran into a linker problem.
gcc -o bin/mtx_gui `pkg-config --libs glfw3 glew` src/main.c
i use this command to compile single main. pkg-config expands into -L/usr/local/lib -lglfw3 -lGLEW -lGLU -lGL which should compile everything. i checked all libs are where they suposed to be. no idea why it is not linking it
main.c:(.text.startup+0x2): undefined reference to `glfwInit'
First, as pointed by G.M in the comment, main.c goes before all libs. second and the most important.
-lglfw3 -lrt -lm -ldl -lpthread -lGL
Libpthread must be also linked, and if you plan on using opengl link Libgl as shown above.

Could not determine size of CHARACTER while installing openmpi

I am trying to install openmpi on Amazon ec2 instance. I have uninstalled the openmpi installations present in the system using -
yum remove -y openmpi.x86_64 openmpi-devel.x86_64
This removes 2.1.1-1.31.amzn1 version of openmpi and openmpi devel.
I have downloaded the tar file from official openmpi site. When I try running configure, I get the following error -
checking if C and Fortran are link compatible... yes
checking to see if Fortran compiler likes the C++ exception flags... skipped (no C++ exceptions flags)
checking to see if mpifort compiler needs additional linker flags... none
checking if Fortran compiler supports CHARACTER... yes
checking size of Fortran CHARACTER... configure: WARNING: Could not determine size of CHARACTER
configure: WARNING: See config.log for details
configure: error: Cannot continue
Errors in config.log file -
configure:37098: $? = 0
configure:37111: result: yes
configure:37146: checking size of Fortran CHARACTER
configure:37214: /usr/lib/a-4.2.0-py-3.5.3-dl-gpu-full/bin/x86_64-conda_cos6-linux-gnu-cc -DNDEBUG -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -finline-functions -fno-strict-aliasing -I. -c conftest.c
configure:37221: $? = 0
configure:37231: gfortran conftestf.f90 conftest.o -o conftest -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
/usr/bin/ld: conftest.o: unrecognized relocation (0x29) in section .text'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
configure:37238: $? = 1
configure:37259: here is the Fortran program:
program fsize
I have tried with ./configure —disable-fortran as well but I am getting the same error.
Any help will be appreciated.

Cannot find ldl lnsl lpthread lrt when buildling?

I am trying to build the RTI perftest in an i86 QNX architecture. When I try to build the makefile that I generated, I get the following:
Checking directory obj/i86QNX6.6qcc_cpp4.7.3/Release
Checking directory ../bin/i86QNX6.6qcc_cpp4.7.3/Release
qcc -V4.7.3,gcc_ntox86 -Y_cpp -lang-c++ -m64 -Wall -o ../bin/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp obj/i86QNX6.6qcc_cpp4.7.3/Release/test.o obj/i86QNX6.6qcc_cpp4.7.3/Release/testPlugin.o obj/i86QNX6.6qcc_cpp4.7.3/Release/testSupport.o obj/i86QNX6.6qcc_cpp4.7.3/Release/Property.o obj/i86QNX6.6qcc_cpp4.7.3/Release/RTIDDSImpl.o obj/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp.o -L/opt/RTI/ndds.5.1.0/lib/i86QNX6.6qcc_cpp4.7.3 -lnddscppz -lnddscz -lnddscorez -lm -lsocket -lpthread -lnsl -lrt -L/usr/lib/nptl
/opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld: cannot find -lpthread
/opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld: cannot find -lnsl
/opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld: cannot find -lrt
cc: /opt/qnx/6.6.0/host/linux/x86/usr/bin/i486-pc-nto-qnx6.6.0-ld error 1
make: *** [../bin/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp] Error 1
I am not to familiar with QNX and its libraries, but when I remove those flags I get a ton of errors. Any tips on how to build the perftest for QNX or dealing with this error would be great, thanks!
My makefile has the following build line which resolves all symbols and results in a running executable:
qcc -o ../bin/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp
obj/i86QNX6.6qcc_cpp4.7.3/Release/test.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/testPlugin.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/testSupport.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/RTIDDSImpl.o
obj/i86QNX6.6qcc_cpp4.7.3/Release/perftest_cpp.o
-L/opt/RTI/rti_connext_dds-5.2.3/lib/i86QNX6.6qcc_cpp4.7.3
-lnddscppz -lnddscz -lnddscorez -lm -lsocket
-V4.7.3,gcc_ntox86 -Y_cpp -lang-c++ -Wall
Note that it has none of the libraries that you mention.

Compiling ghc with -fPIC support

I'm trying to install GHC with -fPIC support in Fedora.
I've grabbed a source tarball since it seems no binary one has this.
In Build.mk i've changed the quick build type to
ifeq "$(BuildFlavour)" "quick"
SRC_HC_OPTS = -H64m -O0 -fasm -fPIC
GhcStage1HcOpts = -O -fasm -fPIC
GhcStage2HcOpts = -O0 -fasm -fPIC
GhcLibHcOpts = -O -fasm -fPIC
SplitObjs = NO
HADDOCK_DOCS = NO
BUILD_DOCBOOK_HTML = NO
BUILD_DOCBOOK_PS = NO
BUILD_DOCBOOK_PDF = NO
endif
unfortunately, when compiling i still get the ld error
ghc -fglasgow-exts --make -shared -oHs2lib.a /tmp/Hs2lib924498/Hs2lib.hs dllmain.o -static -fno-warn-deprecated-flags -O2 -package ghc -package Hs2lib -i/home/phyx/Documents/Haskell/Hs2lib -optl-Wl,-s -funfolding-use-threshold=16 -optc-O3 -optc-ffast-math
Linking a.out ...
/usr/bin/ld: /tmp/Hs2lib924498/Hs2lib.o: relocation R_X86_64_32 against `ghczmprim_GHCziUnit_Z0T_closure' can not be used when making a shared object; recompile with -fPIC
/tmp/Hs2lib924498/Hs2lib.o: could not read symbols: Bad value
So it seems that GHC-prim still isn't compiled with -FPIC
I've also told cabal to build any packages with -fPIC and shared.
Anyone have any ideas?
EDIT:
Thanks to dcouts I've been able to make some progress. But now i'm at the point where I thnk libffi isn't compiled with -fPIC. I've edited the makefile(.in) for it but so far, no luck.
The new command is:
ghc -fPIC -shared dllmain.o Hs2lib.o /usr/local/lib/ghc-7.0.3/libHSrts.a -o Hs2lib.so
where dllmain.c and Hs2lib.hs have both been compiled using -fPIC.
The error I get is:
/usr/bin/ld: /usr/local/lib/ghc-7.0.3/libHSffi.a(closures.o): relocation R_X86_64_32
against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/ghc-7.0.3/libHSffi.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
After you see this error, do the following:
cd /tmp/Hs2lib924498/
ghc -fglasgow-exts --make -shared -oHs2lib.a /tmp/Hs2lib924498/Hs2lib.hs dllmain.o -static -fno-warn-deprecated-flags -fPIC -O2 -package ghc -package Hs2lib -i/home/phyx/Documents/Haskell/Hs2lib -optl-Wl,-s -funfolding-use-threshold=16 -optc-O3 -optc-ffast-math
Note I added -fPIC to the failed ghc command.
Once the command succeeds, continue the compilation from within the tmp directory without cleaning already compiled files. It should skip them and continue where it ended.
There's an FAQ entry on this topic on the Haskell Stack page.
It basically says the problem is environment related and sometimes non-deterministic.
The issue may be related to the use of hardening flags in some cases, specifically those related to producing position independent executables (PIE).
There's also a work around suggestion for Arch Linux:
On Arch Linux, installing the ncurses5-compat-libs package from AUR resolves this issue.

Resources