Is it possible to change glibc's default rpath? [duplicate] - linux

I'm trying to build and install my own gcc 4.7.2 in /usr/local to use in place of the gcc 4.4.6 in /usr. (This is on CentOS 6.3.)
gcc makes executables and dynamic libraries that dynamically link to its own dynamic libraries, e.g. libstdc++.so. How do I build and install gcc so that the generated binaries automatically get a linker -rpath option (-rpath /usr/local/lib64) that causes dynamic libraries in /usr/local/lib64 to be linked instead of those in /usr/lib64 or /lib64?
If it works properly, after I build an executable with the gcc without specifying "-Wl,-rpath=/usr/local/lib64", when I ldd the executable, it should show /usr/local/lib64/libstdc++.so.6 instead of /usr/lib64/libstdc++.so.6. Similarly for the libgcc_s.so.1.
I have tried different approaches, including specifying LDFLAGS_FOR_TARGET=-Wl,-rpath=/usr/local/lib64,-rpath=/usr/local/lib on the 'configure' command-line, but nothing worked.

If you don't want to export paths there's an alternative solution:
with your toolchain in the PATH:
gcc -dumpspecs > specsfile
edit specsfile and in the section link add your -rpath example:
*link:
%{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!static: %{rdynamic:-export-dynamic} -dynamic-linker %(dynamic_linker)} %{static:-static}} -rpath /usr/local/lib64
at this point you can test if it work with:
g++ -specs=specsfile test.cpp
readelf -d a.out |grep RPATH
if it work you can make it permanent (no need to pass -specs everytime)
strace -fF -o /tmp/g++.log g++ test.cpp
grep specs /tmp/g++.log
the grep should show the paths where gcc look for the default specs file.
The specs files are flexible enough to allow conditional linking depending on variables, example:
{!static: %{mabi=n32:-rpath-link %R/lib32:%R/usr/lib32} %{mabi=64:-rpath-link %R/lib64:%R/usr/lib64} %{mabi=32:-rpath-link %R/lib:%R/usr/lib}}
should use different and multiple paths depending on mabi (untested, yet), %R should be the sysroot path, can be changed with needed full path.
There's also a --with-specs= option gcc configure eventually to be used at build time, not clear to me yet how to use with the link section (working on it).
--with-specs="%{shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}%{!shared:-Wl,-rpath -Wl,$(DESTDIR)/lib}"
It work, I used both shared and not !shared just for test, probably some smarter condition should be used, note that it isn't reported with -dumpspecs.
Reading through some thread of the gcc mailing list I had the impression specs aren't liked by everyone (but if I'm not wrong 4.9 add another option --with-extra-specs) instead preferred way to do such customizations appears to be configure.host, but I'm done and not looking into it, have fun! :-)
see also: gcc faq rpath
update above
I don't know if you can set a pre-defined rpath, probably if you can would be in the linker ld of binutils not in gcc/g++, but why would you do that?
Just export LD_LIBRARY_PATH at runtime and LD_RUN_PATH at build time
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
ldd a.out
ldd should show the paths you exported.
To quote a message given when a shared library is built with libtool:
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
add LIBDIR to the `LD_RUN_PATH' environment variable during linking
use the `-Wl,--rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
for completeness
the Makefile I used for testing the thing, all the configure options, environment variables (see boot ldflags) I tried didn't work, --enable-rpath included.
use with mkdir ~/gcc copy the Makefile below into ~/gcc then cd ~/gcc && make build-gcc
notice the options used are only for this test case, don't use as reference.
FETCH = aria2c --file-allocation=none -c -d dl
NICE = nice -n 19
PARALLEL = -j4
DESTDIR = $(HOME)/gcc/install
SRCDIR = $(HOME)/gcc/src
all:
# if more downloads are added just remove {dl,src}/*-my-stamp not the .bak
# the .bak should avoid to rebuild targets because of timestamp
touch_stamp = if [ -f $#.bak ]; then \
touch -r $#.bak $#; \
else \
touch $# $#.bak; \
fi
dl/dl-my-stamp:
$(FETCH) https://ftp.gnu.org/gnu/gcc/gcc-4.7.2/gcc-4.7.2.tar.bz2
$(FETCH) http://ftp.gnu.org/gnu/gmp/gmp-4.3.2.tar.bz2
$(FETCH) ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.1.tar.gz
$(FETCH) https://ftp.gnu.org/gnu/mpfr/mpfr-2.4.2.tar.bz2
$(FETCH) --check-certificate=false http://www.mirrorservice.org/sites/sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2 \
ftp://sourceware.org/pub/binutils/snapshots/binutils-2.24.51.tar.bz2
$(touch_stamp)
untar_dep = src/untar-my-stamp
src/untar-my-stamp: dl/dl-my-stamp
mkdir -p src
tar -C src -xjf dl/gcc-4.7.2.tar.bz2
tar -C src -xjf dl/gmp-4.3.2.tar.bz2
tar -C src -xzf dl/mpc-0.8.1.tar.gz
tar -C src -xjf dl/mpfr-2.4.2.tar.bz2
tar -C src -xjf dl/binutils-2.24.51.tar.bz2
$(touch_stamp)
define configure-rule
$(1)_install = $(DESTDIR)/$(1)-install-my-stamp
$(1)_builddir = $$($(1)_dir)/build
$(DESTDIR)/$(1)-install-my-stamp: $$($(1)_deps)
mkdir -p $$($(1)_builddir)
cd $$($(1)_builddir) && \
$$($(1)_env) ../configure --cache-file=$(SRCDIR)/$(1)-config.cache \
$$($(1)_configure)
$(NICE) make -C $$($(1)_builddir) $$($(1)_make_target) $(PARALLEL)
ifneq ($$($(1)_post_make),)
$$($(1)_post_make)
endif
touch $$#
.PHONY: build-$(1) clean-$(1)
build-$(1): $$($(1)_install)
clean-$(1):
-rm -fr $$($(1)_builddir)
endef
gmp_dir = src/gmp-4.3.2
gmp_env = CONFIG_SITE=$(SRCDIR)/config.site
gmp_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static --enable-cxx
gmp_deps = $(untar_dep)
gmp_make_target = install
$(eval $(call configure-rule,gmp))
mpfr_dir = src/mpfr-2.4.2
mpfr_env = CONFIG_SITE=$(SRCDIR)/config.site
mpfr_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR)
mpfr_deps = $(untar_dep) $(gmp_install)
mpfr_make_target = install
$(eval $(call configure-rule,mpfr))
mpc_dir = src/mpc-0.8.1
mpc_env = CONFIG_SITE=$(SRCDIR)/config.site
mpc_configure = --prefix=$(DESTDIR) \
--disable-shared --enable-static \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR)
mpc_deps = $(untar_dep) $(gmp_install) $(mpfr_install)
mpc_make_target = install
$(eval $(call configure-rule,mpc))
gcc_dir = src/gcc-4.7.2
gcc_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
CXXFLAGS="-I/usr/include/i386-linux-gnu"
gcc_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-local-prefix=$(DESTDIR) \
--with-gmp=$(DESTDIR) --with-mpfr=$(DESTDIR) \
--with-mpc=$(DESTDIR) \
--disable-bootstrap \
--enable-languages=c,c++ \
--disable-libgomp --disable-multilib \
--disable-libmudflap --disable-libssp \
--disable-libquadmath \
--enable-rpath \
MAKEINFO=missing
gcc_deps = $(untar_dep) $(gmp_install) $(mpfr_install) $(mpc_install)
gcc_make_target =
gcc_post_make = make -C $(gcc_builddir) install
$(eval $(call configure-rule,gcc))
binutils_dir = src/binutils-2.24.51
#binutils_env = LDFLAGS=-Wl,-rpath\ $(DESTDIR)/lib
binutils_env = CONFIG_SITE=$(SRCDIR)/config.site \
CFLAGS="-I/usr/include/i386-linux-gnu" \
BOOT_LDFLAGS="-rpath-link=$(DESTDIR)/lib -rpath=$(DESTDIR)/lib"
binutils_configure = --prefix=$(DESTDIR) \
--libdir=$(DESTDIR)/lib \
--with-gmp=$(DESTDIR) \
--enable-rpath
binutils_deps = $(untar_dep) $(gmp_install)
#binutils_make_target = install
binutils_post_make = make -C $(binutils_builddir) install
$(eval $(call configure-rule,binutils))
.PHONY: env
env:
#echo export PATH=$(DESTDIR)/bin:\$$PATH
#echo export LIBRARY_PATH=/usr/lib/i386-linux-gnu

I was installing httpd-2.4.51 and needed to specify -rpath to compile the program. I use the linker flag -Wl,-rpath -Wl,LIBDIR.
Use commands:
sudo mv httpd.c /usr/lib #create a .c file and move it to the default directory for the library file
sudo gcc -o httpd httpd.c -L$--prefix=/usr/lib -lhttpd -Wl,-rpath=$--prefix=/usr/lib
Your can check where you have gcc installed:
whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/share/man/man1/gcc.1.gz

Related

New versions of LD cannot take ELF files as input to link

I have been working on a 32-bit operating system project written in C using GNU LD version 2.34 as the linker.
As part of the build process, I use the following command:
ld -m elf_i386 -nostdlib -T ld/loader.ld build/bootloader/loader.o build/bootloader/loader.elf -o loader_full.elf
When using GNU LD version 2.34, this command succeeds. However, when I use a version higher than this, I get the following error:
ld: cannot use executable file 'build/bootloader/loader.elf' as input to a link
If necessary, here is the full Makefile script:
CC_FLAGS = -g -m32 -ffreestanding -nostartfiles -nostdlib -fno-stack-protector
LD_FLAGS = -m elf_i386 -nostdlib
CC := gcc ${CC_FLAGS}
LD := ld ${LD_FLAGS}
BOOTLOADER_DRIVERS = kernel/drivers/disk/ata.c kernel/drivers/io/screen.c kernel/drivers/utils/mem.c kernel/drivers/utils/ports.c
raw: prep os-image.bin
convert_vmdk: os-image.vmdk
all: prep os-image.bin
ESFS_raw_write: ESFS_raw_write.c
gcc $^ -o $#
# run OS in QEMU
run:
qemu-system-i386 -drive format=raw,file=os-image.bin
# assemble boot sector
build/bootloader/boot_sect.bin: boot/boot_sect.asm
nasm $^ -f bin -o $#
# compile second stage bootloader
build/bootloader/loader_2.o build/drivers/*.o: boot/*.c ${BOOTLOADER_DRIVERS}
${CC} -c $^
mv loader.o build/bootloader/loader_2.o
mv *.o build/drivers/
# link object files into kernel loader
build/bootloader/loader.elf: build/bootloader/loader_2.o build/drivers/*.o
${LD} -T ld/loader.ld $^ -o $#
rm build/bootloader/loader_2.o
# assemble first stage bootloader
build/bootloader/loader.o: boot/loader.asm
nasm $^ -f elf -o $#
# link first and second stage bootloaders
build/bootloader/loader_full.elf: build/bootloader/loader.o build/bootloader/loader.elf
${LD} -T ld/loader.ld $^ -o $#
# make bootloader binary file
build/bootloader/loader.bin: build/bootloader/loader_full.elf
objcopy $^ -O binary $#
./scripts/pad_loader.sh
# clean up unnecessary files
# rm build/bootloader/*.o build/bootloader/*.elf build/drivers/*.o
build/kernel/interrupt.o: kernel/cpu/interrupt.asm
nasm $^ -f elf -o $#
# compile kernel & write to 10MB raw drive image
build/kernel/hdd.bin: kernel/drivers/*/*.c kernel/cpu/*.c kernel/libc/*.c build/kernel/interrupt.o kernel/*.c
${CC} $^ -o build/kernel/kernel.o -T ld/kernel.ld
./scripts/write_kernel_to_drive.sh
# concat 3 boot stages into os-image file
os-image.bin: build/bootloader/boot_sect.bin build/bootloader/loader.bin build/kernel/hdd.bin
cat $^ > $#
os-image.vmdk:
VBoxManage convertfromraw os-image.bin os-image.vmdk --format VMDK
VBoxManage internalcommands sethduuid /home/tim/Dev/OSDev/os-image.vmdk 6372c00a-a62e-4241-9a21-90fa4c22f019
# prepare directory structure for build process
prep:
mkdir -p build/bootloader
mkdir -p build/drivers
mkdir -p build/kernel
# clean up build files and os-image binary
clean:
-rm -rf build/
-rm *.bin *.vmdk
-rm ESFS_raw_write
The project is also on GitHub, so you can build it for yourself:
http://github.com/TimCve/OSDev.git
I have just come up with a similar problem.
It seems ld version GNU ld (GNU Binutils) 2.36.1 links the file into an executable format.
To fix it, add -r in your ld command to output a relocatable format file.
From the ld manual:
-r
--relocateable
Generate relocatable output--i.e., generate an output file that can in turn serve as input to ld. This is often called partial linking. As a side effect, in environments that support standard Unix magic numbers, this option also sets the output file's magic number to OMAGIC. If this option is not specified, an absolute file is produced. When linking C++ programs, this option will not resolve references to constructors; to do that, use -Ur. This option does the same thing as -i.
It's not that ld can't take ELF files as input. It's that it won't take executable files as input. The error is:
ld: cannot use executable file '...' as input to a link
See https://sourceware.org/bugzilla/show_bug.cgi?id=26223
Does it work to simply use chmod -x $# after building the .elf file?
In my (eclipse-based) multicore MCUXpresso project, I had to add this line to my post-build steps to modify a byte inside of the generated "*.o" file so the linker step which used that file wouldn't complain anymore. This happened after I updated to version 11.6 which includes the LD version mentioned previously. I originally found this on the forums for NXP MCUXpresso, but I assume it will work similarly for just about anyone:
dd if=/dev/zero of="${BuildArtifactFileName}.o" bs=1 seek=16 conv=notrunc count=2
NXP MCUXpresso fix

Yocto Multifile compilation

I have 4 files in different directories.
1. /home/Linux/NXP/XYZ/Embedded/Read/read.c
2. /home/Linux/NXP/XYZ/Embedded/main/mainfun.c
3. /home/Linux/NXP/XYZ/Embedded/write/write.c
4. /home/Linux/NXP/XYZ/Embedded/config/config.c
and the .bb file is located at
"/home/Linux/NXP/yocto/jethro/yocto/source/meta-mylayer/recipes-app/mainfun/mainfun.bb"
From mainfun.c I am calling different functions, the definitions of which are present inside write.c, config.c, read.c.
I have only come across a single file compilation using yocto so can you please help how do I write the .bb file? How can I compile and generate "XYZ_app" executable?
Here I attached my .bb file which I have written but it's not working:
DESCRIPTION = "multiple file compilation"
PR = "r0"
LICENSE = "CLOSED"
SRC_URI += "file://home/Linux/NXP/XYZ/Embedded/ \
"
S = "${WORKDIR}"
do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/read/read.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/write/write.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/conf/conf.c
${CC} ${CFLAGS} ${LDFLAGS} --static -c ${WORKDIR}}/home/Linux/NXP/XYZ/Embedded/mainfun/mainfun.c
${CC} ${CFLAGS} ${LDFLAGS} --static ${WORKDIR} /home/Linux/NXP/XYZ/Embedded/Read/read.o /home/Linux/NXP/XYZ/Embedded/write/write.o /home/Linux/NXP/XYZ/Embedded/conf/conf.o /home/Linux/NXP/XYZ/Embedded/mainfun/mainfun.o -c XYZ_App
}
do_install() {
install -m 0755 -d ${D}${bindir}
install -m 0755 ${S}/XYZ_App ${D}${bindir}
}
The direct compilation of source files in a recipe is a testing/emergency solution at best. Whenever it comes to something even only slightly advanced, the correct way is to use a build system of any kind.
Those directly supported in OpenEmbedded include (amongst others)
Makefiles
Autotools
CMake
Here are examples for a couple of recipes for those systems: http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#new-recipe-testing-examples
Properly packing the sources up also gives you a way to easily test the compilation and application without having to invoke the whole bitbake process. All of them have pros and cons, so you might want to dig a deep further. For a start into autotools, this seems to be a good thing:
https://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en
An alternative is to look at GNU hello, and also the corresponding recipe.

Why does this makefile only work with a single job?

I'm trying to write a Makefile which compiles a cross compiler.
It downloads GCC and binutils, extract the archive, run the configure script and run make.
This is the Makefile I wrote:
# Versions
GCC_VERSION := 6.3.0
BINUTILS_VERSION := 2.27
# Build
TARGET ?= i686-elf
PREFIX := $(realpath build)
# Phony tasks
.PHONY: all clean gcc binutils
# Targets
BINUTILS_TARGETS := build/bin/${TARGET}-addr2line build/bin/${TARGET}-ar \
build/bin/${TARGET}-as build/bin/${TARGET}-c++filt \
build/bin/${TARGET}-elfedit build/bin/${TARGET}-gprof \
build/bin/${TARGET}-ld build/bin/${TARGET}-ld.bfd build/bin/${TARGET}-nm \
build/bin/${TARGET}-objcopy build/bin/${TARGET}-objdump \
build/bin/${TARGET}-ranlib build/bin/${TARGET}-readelf \
build/bin/${TARGET}-size build/bin/${TARGET}-strings \
build/bin/${TARGET}-strip
GCC_TARGETS := build/bin/${TARGET}-cpp build/bin/${TARGET}-gcc \
build/bin/${TARGET}-gcc-${GCC_VERSION} build/bin/${TARGET}-gcc-ar \
build/bin/${TARGET}-gcc-nm build/bin/${TARGET}-gcc-ranlib \
build/bin/${TARGET}-gcov build/bin/${TARGET}-gcov-tool
# Aliases
all: binutils gcc
gcc: ${GCC_TARGETS}
binutils: ${BINUTILS_TARGETS}
# Download the packages
packages/gcc-${GCC_VERSION}.tar.bz2:
curl ftp://ftp.gnu.org/gnu/gcc/gcc-${GCC_VERSION}/gcc-${GCC_VERSION}.tar.bz2 \
-o $#
packages/binutils-${BINUTILS_VERSION}.tar.bz2:
curl ftp://ftp.gnu.org/gnu/binutils/binutils-${BINUTILS_VERSION}.tar.bz2 \
-o $#
# Extract them
packages/gcc-${GCC_VERSION}/configure: packages/gcc-${GCC_VERSION}.tar.bz2
tar -xmjf $< -C packages
packages/binutils-${BINUTILS_VERSION}/configure: packages/binutils-${BINUTILS_VERSION}.tar.bz2
tar -xmjf $< -C packages
# Build them
${GCC_TARGETS}: packages/gcc-${GCC_VERSION}/configure
mkdir -p build/gcc
cd build/gcc && ../../packages/gcc-${GCC_VERSION}/configure \
--target=${TARGET} --prefix=${PREFIX} --disable-nls \
--enable-languages=c --without-headers && make all-gcc && \
make all-target-libgcc && make install-gcc && make install-target-libgcc
${BINUTILS_TARGETS}: packages/binutils-${BINUTILS_VERSION}/configure
mkdir -p build/binutils
cd build/binutils && ../../packages/binutils-${BINUTILS_VERSION}/configure \
--target=${TARGET} --prefix=${PREFIX} --with-sysroot --disable-nls \
--disable-werror && make && make install
# Clean everything
clean:
rm -rf build/*
rm -rf packages/*
It works when running make with no options, but when I use the jobs option, it fails (but not everytime): it download binutils and GCC in parallel.
When binutils is fully downloaded, it extracts it and compiles it, then the GCC download ends, but it doesn't do anything and there are no errors.
Also sometimes the compilation of GCC or binutils fails with strange errors (I will edit this post with some of them).
Not sure about the exact source of your specific build failures, but the Makefile is problematic: the 2 build rules have multiple targets. Make does not support this well, see here for an explanation.
Make with jobs fails because it starts multiple instances of the same recipe but these instances can't run together correctly.
${GCC_TARGETS}: packages/gcc-${GCC_VERSION}/configure
mkdir -p build/gcc
cd build/gcc && ../../packages/gcc-${GCC_VERSION}/configure ... make ...
This is trouble maker, I guess, because Make with jobs initiates multiple configure invocations in the same directory to run asynchronously. So you have multiple configure scripts running and adding bits to the same directory. And then multiple instances of Make are invoked in the same build directory. Perfect mess.
Something like:
${GCC_TARGETS}: packages/gcc-${GCC_VERSION}/configure
mkdir -p build/gcc/$(nodir $#) && cd build/gcc/$(nodir $#) ...
Should fix the problem by means of starting configure & make sequences in different directories. You need similar fix for ${BINUTILS_TARGETS} too.

how to link your project to a library of 64 bit in makefile

I am a beginner developer in makefile and have a project that includes a src directory. Inside the src directory there are some .c and .h files as follows:
file1.c, file2.c, main.c, header1.h and header2.c. Main depends on file2.c while file2.c depends on file1.c. Each file should be linked to non standard libraries that I have and a non standard include directory, too. The libraries directory and the include directory are /usr/lib/srr__lib and /usr/bin/srr__bin respectively. I wrote two makefiles one at the src directory and the other one at the root directory of the project. The src makefile is as shown below:
CC = gcc
TARGETDIR_PR=GNU-amd64-Linux
all: $(TARGETDIR_PR)/PR
OBJS_PR = \
$(TARGETDIR_PR)/file1.o \
$(TARGETDIR_PR)/file2.o \
$(TARGETDIR_PR)/main.o
AM_CPPFLAGS = \
-DPACKAGE_LOCALE_DIR=\""$(localedir)"\" \
-DPACKAGE_SRC_DIR=\""$(srcdir)"\" \
-DPACKAGE_DATA_DIR=\""$(pkgdatadir)"\"
AM_CFLAGS =\
-g -I/usr/bin/srr__bin
bin_PROGRAMS = PR
PR_4_SOURCES = \
file1.c \
file2.c \
main.c
PR_LDFLAGS =
PR_LDADD = -L/usr/lib/srr__lib -lsrr__ml__sharedmem_4core -lprdependency -lsrrdsl___wrapper_library__ml -lsrrdynarray -lsrrdynarray_pic -lsrrhistogram -lsrrhistogram_pic -lsrrlistofarrays -lsrrlistofarrays_pic -lsrrmalloc -lsrrparam -lsrrparam_pic -lsrrqueue -lsrrqueue_pic -lvreo_wrapper_library
$(TARGETDIR_PR)/PR: $(TARGETDIR_PR) $(OBJS_PR)
$(LINK.c) $(AM_CFLAGS) $(AM_CPPFLAGS) -o $# $(OBJS_PR) $(PR_LDADD)
$(TARGETDIR_PR)/SeedVP.o: $(TARGETDIR_PR) SeedVP.c
$(COMPILE.c) $(AM_CFLAGS) $(AM_CPPFLAGS) -o $# file1.c
$(TARGETDIR_PR)/Task.o: $(TARGETDIR_PR) Task.c
$(COMPILE.c) $(AM_CFLAGS) $(AM_CPPFLAGS) -o $# file2.c
$(TARGETDIR_PR)/main.o: $(TARGETDIR_PR) main.c
$(COMPILE.c) $(AM_CFLAGS) $(AM_CPPFLAGS) -o $# main.c
clean:
rm -f \
$(TARGETDIR_PR)/PR \
$(TARGETDIR_PR)/file1.o \
$(TARGETDIR_PR)/file2.o \
$(TARGETDIR_PR)/main.o
rm -f -r $(TARGETDIR_PR)
# Create the target directory (if needed)
$(TARGETDIR_PR):
mkdir -p $(TARGETDIR_PR)
# Enable dependency checking
.KEEP_STATE:
.KEEP_STATE_FILE:.make.state.GNU-amd64-Linux
and the makefile of the root directory is as shown below :
SUBDIRS = src
PRDSL_4docdir = ${prefix}/doc/PR
PRdoc_DATA = \
README\
COPYING\
AUTHORS\
ChangeLog\
INSTALL\
NEWS
INTLTOOL_FILES = intltool-extract.in \
intltool-merge.in \
intltool-update.in
EXTRA_DIST = $(PRdoc_DATA) \
$(INTLTOOL_FILES)
DISTCLEANFILES = intltool-extract \
intltool-merge \
intltool-update \
po/.intltool-merge-cache
# Remove doc directory on uninstall
uninstall-local:
-rm -r $(PRdocdir)
I run all the autotools command successfully and the ./configure then make and the project didn't complain; no error at the make but when I run the generated executable file as ./PR it complains and gave the error below:
error while loading shared libraries: libsrr__ml__sharedmem_4core.so:
cannot open shared object file: No such file or directory
i think it's maybe an error in linking as the library is 64 bit and my machine is 64 also. But, how can I mention this in the makefile? Any help will be appreciated.
When running the program run it this way
export LD_LIBRARY_PATH=/usr/lib/srr__lib
./executable_file
or edit /etc/ld.so.conf and add the line
/usr/lib/srr__lib
and run ldconfig as root.

Eclipse can't find 32bit ncurses library

I am running Ubuntu and need to use a 32 bit version of ncurses with my program. I downloaded ncurses-5.9 using wget from http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.9.tar.gz. I then entered:
gzip -dc < ncurses-5.9.tar.gz | tar -xf -
cd ncurses-5.9
At this point I followed all the instructions listed here (I have listed them below as well:
CC="gcc ${BUILD32}" CXX="g++ ${BUILD32}" \
./configure --prefix=/usr --libdir=/lib \
--with-shared --without-debug --enable-widec \
--with-manpage-format=normal \
--with-default-terminfo-dir=/usr/share/terminfo
make
make install
mv -v /usr/bin/ncursesw5-config{,-32}
mv -v /lib/lib{panelw,menuw,formw,ncursesw,ncurses++w}.a /usr/lib
rm -v /lib/lib{ncursesw,menuw,panelw,formw}.so
ln -svf ../../lib/libncursesw.so.5 /usr/lib/libncursesw.so
ln -svf ../../lib/libmenuw.so.5 /usr/lib/libmenuw.so
ln -svf ../../lib/libpanelw.so.5 /usr/lib/libpanelw.so
ln -svf ../../lib/libformw.so.5 /usr/lib/libformw.so
All of these commands executed successfully. When I go to run my program however, I use the appropriate flag -lncurses yet I get back the error: /usr/bin/ld: cannot find -lncurses
From the terminal I can see that libncurses libncurses++w.a libncursesw.a libncursesw.so are all in /usr/lib and ncurses5-config ncursesw5-config-32
are in /usr/lib.
Please advise as to what I should try to change, thanks much!

Resources