ELDK gcc linker error in ld.so.1 - c

I have ELDK-3.1 installed in a Ubuntu box working perfectly.
In another machine, running 64 bits OpenSuse 12.1, I cloned the ELDK installation and, for some time it worked very well.
Now when I try to configure my projects I see:
configure: error: C compiler cannot create executables
See `config.log' for more details
And the log shows:
configure:3411: ppc-linux-gcc conftest.c >&5
/opt/ELDK-3.1/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/../../../../ppc-linux/bin/ld: warning: ld.so.1, needed by /opt/ELDK-3.1//usr/../ppc_8xx/lib/libc.so.6, not found (try using -rpath or -rpath-link)
/opt/ELDK-3.1//usr/../ppc_8xx/lib/libc.so.6: undefined reference to `_dl_lookup_versioned_symbol_skip#GLIBC_PRIVATE'
...
The file ld.so.1 is in the same directory as libc.so.6.
s -l /opt/ELDK-3.1//usr/../ppc_8xx/lib/ld.so.1
lrwxrwxrwx 1 root root 11 Jan 31 11:43 /opt/ELDK-3.1//usr/../ppc_8xx/lib/ld.so.1 -> ld-2.3.1.so
As far as I can see, I am correctly defining all the needed environment and trying to build using exactly the same build system as in the Ubuntu box (the project is "automaked").
So I wrote a script trying to mimic everything my automaked configure does:
#!/bin/bash
if [ ! -f confdefs.c ]; then
cat > confdefs.c << EOF
/* confdefs.h */
#define PACKAGE_NAME "xyz"
#define PACKAGE_TARNAME "xyz"
#define PACKAGE_VERSION "1.00"
#define PACKAGE_STRING "xyz 1.00"
#define PACKAGE_BUGREPORT "<contact#company>"
#define PACKAGE_URL ""
#define PACKAGE "xyz"
#define VERSION "1.00"
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
EOF
fi
ARCH=powerpc
export CROSS_COMPILE=ppc_8xx
TOOLCHAIN=ppc-linux-
TOOLCHAIN_ROOT=/opt/ELDK
LD=`which ${TOOLCHAIN}ld`
CC=`which ${TOOLCHAIN}gcc`
GCC=$CC
export CFLAGS="-Wall -g -I${TOOLCHAIN_ROOT}/ppc_8xx/usr/include/"
export CPPFLAGS=$CFLAGS
# export LDFLAGS="-shared"
$CC $CFLAGS $LDFLAGS confdefs.c -o confdefs
This gives me exactly the same error as configure.
If I uncomment the line export LDFLAGS="-shared", on the other hand, it builds perfectly!.
> ls -l confdefs
-rwxr-xr-x 1 myself users 16136 Fev 1 09:52 confdefs
> file confdefs
confdefs: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, not stripped
Could anybody here please give me any clue of what I am missing so that my projects work finely on one box and not in the other?
Thanks!

I'm not 100% sure that it solves all problems, but it works for us.
We discovered that symlink "ld.so.1 -> ../../../ppc_8xx/lib/ld.so.1" to eldk-3.1/usr/ppc-linux/lib solves linking error.
I suspect something changed with environment between F15 and F16. Same for OpenSUSE (11->12).
Also bug was submitted against Fedora https://bugzilla.redhat.com/show_bug.cgi?id=754695 which was terminated as intentional ABI changes.

Related

Unable to compile PnetCDF: 'tst_rec_vars' test fails

I am trying to install PnetCDF from source. I used the 1.12.2 version for installation. MPICH, Zlib, Szip, HDF5 and NetCDF-4 have been installed from source successfully (HDF5 and NetCDF-4 have been built with parallel I/O support).
MPICH is installed as follows (v3.4.2):
./configure --prefix=${DIR}/mpich --with-device=ch4:ofi CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" --enable-fortran
make
make check
make install
export PATH=${DIR}/mpich/bin:${PATH}
Where DIR is the root directory all the libraries are installed to (with their own directory).
Zlib (v1.2.11):
./configure --prefix=${DIR}/grib2
make
make check
make install
export CPPFLAGS="-I${DIR}/grib2/include"
export LDFLAGS="-L${DIR}/grib2/lib"
export LD_LIBRARY_PATH="${DIR}/grib2/lib:$LD_LIBRARY_PATH"
Szip (v2.1.1):
./configure --prefix=${DIR}/szip
CC=mpicc
make
make check
make install
export LD_LIBRARY_PATH="${DIR}/szip/lib:$LD_LIBRARY_PATH"
export CPPFLAGS="-I${DIR}/szip/include ${CPPFLAGS}"
export LDFLAGS="-L${DIR}/szip/lib ${LDFLAGS}"
HDF5 (v1.8.22):
export HDF5=${DIR}/hdf5
./configure --prefix=${HDF5} --with-szlib=${DIR}/szip --with-zlib=${DIR}/grib2 --enable-parallel CC=mpicc --enable-fortran FC=mpifort
make
make check
make install
export LD_LIBRARY_PATH="${HDF5}/lib:$LD_LIBRARY_PATH"
export CPPFLAGS="-I${HDF5}/include ${CPPFLAGS}"
export LDFLAGS="-L${HDF5}/lib ${LDFLAGS}"
export PATH="${HDF5}/bin:${PATH}"
NetCDF4-C (v4.8.0):
./configure --prefix=${DIR}/netcdf --disable-dap --enable-parallel-tests --enable-large-file-tests --disable-extreme-numbers CC=mpicc
make
make check
make install
export PATH="${NETCDF}/bin:${PATH}"
export LD_LIBRARY_PATH="${NETCDF}/lib:${LD_LIBRARY_PATH}"
export CPPFLAGS="-I${NETCDF}/include ${CPPFLAGS}"
export LDFLAGS="-L${NETCDF}/lib ${LDFLAGS}"
export LIBS="$(nc-config --libs) ${LIBS}"
NetCDF4-Fortran (v4.5.3):
./configure --prefix=${NETCDF} --enable-large-file-tests --enable-parallel-tests CC=${DIR}/mpich/bin/mpicc FC=mpifort F77=mpif77
make
make check
make install
The HDF5 configuration shown by h5pcc -showconfig is given below (only the part I think relevant is included):
Features:
---------
Parallel HDF5: yes
High-level library: yes
Build HDF5 Tests: yes
Build HDF5 Tools: yes
Threadsafety: no
Default API mapping: v18
With deprecated public symbols: yes
I/O filters (external): deflate(zlib),szip(encoder)
MPE:
Direct VFD: no
(Read-Only) S3 VFD: no
(Read-Only) HDFS VFD: no
dmalloc: no
Clear file buffers before write: yes
Using memory checker: no
Function stack tracing: no
Strict file format checks: no
Optimization instrumentation: no
And the output of nc-config --all:
--cc -> /media/case/work/hwrf/libraries/mpich/bin/mpicc
--cflags -> -I/media/case/work/hwrf/libraries/netcdf/include -I/media/case/work/hwrf/libraries/hdf5/include -I/media/case/work/hwrf/libraries/szip/include -I/media/case/work/hwrf/libraries/grib2/include
--libs -> -L/media/case/work/hwrf/libraries/netcdf/lib -lnetcdf
--static -> -lhdf5_hl -lhdf5 -lm -ldl -lz -lcurl
--has-c++ -> no
--cxx ->
--has-c++4 -> no
--cxx4 ->
--has-fortran -> yes
--fc -> mpifort
--fflags -> -I/media/case/work/hwrf/libraries/netcdf/include -I/media/case/work/hwrf/libraries/netcdf/include
--flibs -> -L/media/case/work/hwrf/libraries/netcdf/lib -lnetcdff
--has-f90 ->
--has-f03 -> yes
--has-dap -> no
--has-dap2 -> no
--has-dap4 -> no
--has-nc2 -> yes
--has-nc4 -> yes
--has-hdf5 -> yes
--has-hdf4 -> no
--has-logging -> no
--has-pnetcdf -> no
--has-szlib -> yes
--has-cdf5 -> yes
--has-parallel4 -> yes
--has-parallel -> yes
--has-nczarr -> no
--prefix -> /media/case/work/hwrf/libraries/netcdf
--includedir -> /media/case/work/hwrf/libraries/netcdf/include
--libdir -> /media/case/work/hwrf/libraries/netcdf/lib
--version -> netCDF 4.8.0
So far, so good. Everything was installed without any failure. All make checks have been passed.
The trouble arises when I try to compile PnetCDF from source. I tried PnetCDF version 1.11.2 for installation (in fact, I triedd several older versions as well, more on that later). The installation is attempted as following:
./configure --prefix=${DIR}/pnetcdf --enable-large-single-req --enable-netcdf4 --enable-shared=yes --with-netcdf4="${DIR}/netcdf" MPICC=mpicc MPIF77=mpif77 MPIF90=mpif90 MPICC=mpicc MPIF77=mpif77 MPIF90=mpif90
make
make tests
make check
make ptest
make ptests
But, it fails at make ptest. The failed test is tst_rec_vars.c and the error message is:
Error at line 78 of tst_rec_vars.c: expect dim X len 4 but got 3
Error at line 78 of tst_rec_vars.c: expect dim X len 4 but got 3 fail with 2 mismatches
make[2]: *** [Makefile:1354: ptest4] Error 1
make[2]: Leaving directory '/media/case/work/hwrf/libraries/source/pnetcdf-1.12.2/test/nc4'
make[1]: *** [Makefile:780: ptests] Error 1
make[1]: Leaving directory '/media/case/work/hwrf/libraries/source/pnetcdf-1.12.2/test'
make: *** [Makefile:965: ptests] Error 1
Heres the test that is failing (GitHub link): tst_rec_vars.c
It seems that the test is checking a NetCDF file for the lenth of dimension in it. I assume the NetCDF file it is checking is tst_rec_vars.nc. The output of ncdump -h on this file is given below:
netcdf tst_rec_vars {
dimensions:
X = UNLIMITED ; // (4 currently)
variables:
int U(X) ;
int V(X) ;
}
That is, the NetCDF file's X dimension indeed has a length 4, although the test program beleives it is only 3. But, if I were to run the test manually as ./tst_rec_vars, it runs correctly.
*** TESTING C tst_rec_vars for record variables to NetCDF4 file ------ pass
Could it be due to parallel processing/threading? The test in question is run under a section titled test/nc4: Parallel testing on 4 MPI processes. I assume the NetCDF file was tested before it was formed completely, which could explain why I got a length 1 X dimension in the NetCDF file from ncdump at one point.
>>>ncdump -h tst_rec_vars.nc
netcdf tst_rec_vars {
dimensions:
X = UNLIMITED ; // (1 currently)
variables:
int U(X) ;
int V(X) ;
}
What exactly is going on here? How do I fix it?
Edit:
I'm trying to install it on CentOS 7, since I was encountering the above mentioned issue, I tried to install it on a Debian 11 system. But I am getting the very exact error in both systems.

Discrepancy in behavior of Linux loaders (ld-linux-x86-64) between Glibc 2.12 and Glibc 2.17

I'm trying to compile the same lib on two x86 separate machines.
Both use the same toolchain (exactly same set of files) but have different Glibc versions.
When I run command LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --list ./libl2ps.so I notice the following discrepancy between the 2 Linux loaders:
Machine 1 (with Glibc 2.12):
19943: find library=libm.so.6 [0]; searching
19943: search path=/ebs/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64:...:/ebs/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/. (RPATH from file ./libl2ps.so)
19943: trying file=/ebs/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm.so.6
19943:
19943: find library=libgcc_s.so.1 [0]; searching
...
In this case the Linux loader selects lib libm.so.6 from the toolchain path based on RPATH of lib libl2ps.so.
Machine 2 (with Glibc 2.17):
10699: find library=libm.so.6 [0]; searching
10699: search path=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64:/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/lib64:/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib:/home/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/. (RPATH from file ./libl2ps.so)
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/lib64/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib/libm.so.6
10699: trying file=/home/frperies/repo/gnb/uplane/build_bbp/l2_ps/build/./libm.so.6
10699: search cache=/etc/ld.so.cache
10699: trying file=/lib64/libm.so.6
As for Machine 1, the loader attempts from RPATH of libl2ps.so to select lib libm.so.6 from toolchain path but skip it for some reason and try further other paths. Finally it selects libm.so.6from the system path /lib64/.
The RPATH of the 2 libs lib2ps.so are exactly the same. The two files libm.so.6 are also exactly the same on both machines (checked with md5sum).
I don't understand this differences of behavior between the 2 Linux loaders.
Do you see any reason what would explain this discrepancy ?
Thank you very much for your answers.
Update:
Thank you yugr for your answer.
Output of readelf -h gives only differences on fields "Entry point address" and "Start of section headers" and there is no other differences so I think it will not help.
Regarding using dlopen()/dlerror(), I've done a little executable with the following statement:
dlopen("/home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so", RTLD_LAZY);
On machine 1 it works as expected:
C++ dlopen demo
Opening libm-2.28.so...
Closing library...
On machine 2 it fails and dlerror() gives the following output:
Cannot open library: /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so: cannot open shared object file: No such file or directory
but the file libm-2-28.so really exists on my file system:
$ ls -l /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic-linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so
-rwxr-xr-x 1 frperies linseeusers_lte_espoo 1682944 Oct 5 13:50 /home/frperies/repo/gnb/uplane/build/prefix-root/asik-x86_64-ps_lfs-dynamic- linker-on/toolchain/sysroots/core2-64-pc-linux-gnu/usr/lib64/libm-2.28.so
This is very weird, what could lead to this situation ???
Thanks
Update 2:
That is true that I haven't pointed out that machine 1 is a RHEL6.8 distro while machine 2 is RHEL7.4 distro. I (naively?) didn't think this really matters...
On machine 1:
$ cat /proc/sys/kernel/osrelease
4.4.115-1.NSN.el6.x86_64
$ uname -a
Linux sq24-3 4.4.115-1.NSN.el6.x86_64 #1 SMP Mon Feb 12 12:35:46 CET 2018 x86_64 x86_64 x86_64 GNU/Linux
$ readelf -n libl2ps.so
Notes at offset 0x00000270 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: b598468830fdf2f61eda25553b9a367c4d28cdc9
On machine 2:
$ cat /proc/sys/kernel/osrelease
3.10.0-693.el7.x86_64
$ uname -a
Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
$ readelf -n libl2ps.so
Displaying notes found at file offset 0x00000270 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 5829181bc0502233748149369108915ea7b10e8f
Does it help ?
Thanks
Update 3:
$ readelf -n libm.so.6
Notes at offset 0x00000238 with length 0x00000024:
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 0d84c7247dd76008c096719043e5592735a1c4bd
Notes at offset 0x0000025c with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 4.4.0
So, how to interpret this ABI version number set to 4.4.0 ??
Thanks
Thank you yugr and Employed Russian for your answers!!
I will give it a try by upgrading my Kernel version on Machine 2.
Thanks
Regards
The error message that you see is the infamously confusing ENOENT errno. I see two instances of it in dl-load.c:
checking OS compatibility
loading non-setuid to setuid process
I suspect the first one fails in your case which would mean that OS kernel is incompatible between two machines. ld.so manpage indeed says that
Each shared object can inform the dynamic linker of the
minimum kernel ABI version that it requires. (This
requirement is encoded in an ELF note section that is viewable
via readelf -n as a section labeled NT_GNU_ABI_TAG.) At run
time, the dynamic linker determines the ABI version of the
running kernel and will reject loading shared objects that
specify minimum ABI versions that exceed that ABI version.
NT_GNU_ABI_TAG is 4.4.0 which means that you run a program expecting a minimum 4.4 kernel on a 3.10 kernel. Theoretically newer Glibc should run on older kernels as well but in your case Glibc was probly built with explicit --enable-kernel flag which prevents it's usage on kernels before 4.4 (see e.g. this explanation of --enable-kernel).
As a workaround, you may try to fool Glibc by overriding kernel version on machine 2 via
export LD_ASSUME_KERNEL=4.4.0
but it may not work if libm makes 4.4-specific syscalls that are not really present on 3.10.

How to distribute an application using shared library on Linux

My app uses library: boost, ffmpeg (avcodec, avformat,...). I want to pack my app to run on Ubuntu 14 or higher. I don't want to use static build.
I have checked on some computers which install Ubuntu. Here is results:
Ubuntu 14.04:
ls -l libavcodec*
libavcodec.a
libavcodec.so -> libavcodec.so.54.35.1
libavcodec.so.54.35.1
ls -l libboost_thread*
libboost_thread.a
libboost_thread.so -> libboost_thread.so.1.54.0
libboost_thread.so.1.54.0
Ubuntu 16.04:
ls -l libavcodec*
libavcodec.a -> libavcodec-ffmpeg.a
libavcodec-ffmpeg.a
libavcodec-ffmpeg.so -> libavcodec-ffmpeg.so.56.60.100
libavcodec-ffmpeg.so.56 -> libavcodec-ffmpeg.so.56.60.100
libavcodec-ffmpeg.so.56.60.100
libavcodec.so -> libavcodec-ffmpeg.so
ls -l libboost_thread*
libboost_thread.a
libboost_thread.so -> libboost_thread.so.1.58.0
libboost_thread.so.1.58.0
My app
objdump -p ControlStation | grep NEEDED
NEEDED libavcodec-ffmpeg.so.56
NEEDED libavformat-ffmpeg.so.56
NEEDED libavutil-ffmpeg.so.54
NEEDED libswscale-ffmpeg.so.3
NEEDED libboost_system.so.1.58.0
NEEDED libboost_thread.so.1.58.0
....
I compile on Ubuntu 16, so my app uses file libavcodec-ffmpeg.so.56 and libboost_thread.so.1.58.0. Therefore, it couldn't run on other computers.
Normally, a shared library should be
libName.so ---> libName.so.MAJOR
libName.so.MAJOR --> real library file
But ffmpeg has many versions, boost library doesn't have symbolic file libboost_thread.so.1
Could anyone help me about this problem ? Thank you !

Compiling perl >5.10 on AIX version 5.3

I've been compiling OpenSSL (and thus Perl >5.10, as it is a dependency) on multiple platforms. I've managed to get 1.1.0b compiled on every single platform except AIX, which I can't even compile Perl. I've tried several versions and looked at the documentation Perl provides online. From what I can tell, it suggests version 5.12.2.
When I attempt to compile version 5.12.2,
I take the following from the documentation, and fill in a few local system variables, such as using XLC rv7.
export OBJECT_MODE=64
./Configure \
-d \
-Dcc=/usr/vac/bin/xlc_r7 \
-Duseshrplib \
-Duse64bitall \
-Dprefix=`pwd`/../PERL
Then I attempt to make as prompted, and get the following error:
/usr/vac/bin/xlc_r7 -q64 -o miniperl -brtl -bdynamic -L/usr/local/lib -b64 gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o miniperlmain.o opmini.o perlmini.o -lbind -lnsl -ldl -lld -lm -lcrypt -lc
LIBPATH=.../perl-5.12.2 ./miniperl -w -Ilib -MExporter -e '<?>' || make minitest
LIBPATH=.../perl-5.12.2 ./miniperl -Ilib autodoc.pl
/usr/bin/ln -s perl5122delta.pod pod/perldelta.pod
LIBPATH=.../perl-5.12.2 ./miniperl -Ilib -Icpan/Cwd -Icpan/Cwd/lib pod/perlmodlib.PL -q
readdir(./../../../../..): Bad file number at lib/FindBin.pm line 116
stat(/pod/): No such file or directory at lib/FindBin.pm line 197
stat(/pod/): No such file or directory at lib/FindBin.pm line 200
Use of chdir('') or chdir(undef) as chdir() is deprecated at pod/perlmodlib.PL line 9.
No such file or directory at pod/perlmodlib.PL line 19.
make: The error code from the last command is 2.
Taking a look at pod/perlmodlib.PL, we see the following:
# MANIFEST itself is Unix style filenames, so we have to assume that Unix style
# filenames will work.
open (MANIFEST, "../MANIFEST") or die $!;
In my desperation I tried to hack it up and avoid writing to the manifest, but then I get this issue:
Creating Makefile.PL in cpan/Archive-Extract for Archive::Extract
Running Makefile.PL in cpan/Archive-Extract
../../miniperl Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.a
readdir(./../../../../../../..): No such file or directory at ../../lib/File/Find.pm line 610
Use of chdir('') or chdir(undef) as chdir() is deprecated at ../../lib/File/Find.pm line 773.
readdir(./../../..): No such file or directory at ../../cpan/Cwd/lib/File/Spec/Unix.pm line 483
Could not open 'lib/Archive/Extract.pm': No such file or directory at ../../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm line 2588.
512 from cpan/Archive-Extract's Makefile.PL at make_ext.pl line 390.
Warning: No Makefile!
make: Cannot find a rule to create target config from dependencies.
Stop.
make config PERL_CORE=1 LIBPERL_A=libperl.a failed, continuing anyway...
Making all in cpan/Archive-Extract
make all PERL_CORE=1 LIBPERL_A=libperl.a
make: Cannot find a rule to create target all from dependencies.
Stop.
Unsuccessful make(cpan/Archive-Extract): code=512 at make_ext.pl line 449.
make: The error code from the last command is 2.
The frequency of errors makes me feel like perhaps I don't have something configured right...
My next thought was to try the most updated version, which at the time of writing is 5.24. Using the same configuration and attempting to make I get the following issue:
Can't locate strict.pm in #INC (you may need to install the strict module) (#INC contains: /cpan/AutoLoader/lib /dist/Carp/lib /dist/PathTools /dist/PathTools/lib /cpan/ExtUtils-Install/lib /cpan/ExtUtils-MakeMaker/lib /cpan/ExtUtils-Manifest/lib /cpan/File-Path/lib /ext/re /dist/Term-ReadLine/lib /dist/Exporter/lib /ext/File-Find/lib /cpan/Text-Tabs/lib /dist/constant/lib /cpan/version/lib /lib .) at autodoc.pl line 25.
BEGIN failed--compilation aborted at autodoc.pl line 25.
make: The error code from the last command is 2.
Which I know from other compilations means I need to edit the PERL5LIB variable.
If I keep adding all the modules to the path:
export PERL5LIB=`pwd`/dist/Exporter/lib:$PERL5LIB
export PERL5LIB=`pwd`/cpan/Text-Tabs/lib:$PERL5LIB
export PERL5LIB=`pwd`/ext/re:$PERL5LIB
export PERL5LIB=`pwd`/dist/constant/lib:$PERL5LIB
export PERL5LIB=`pwd`/cpan/ExtUtils-MakeMaker/lib:$PERL5LIB
export PERL5LIB=`pwd`/dist/Carp/lib:$PERL5LIB
export PERL5LIB=`pwd`/cpan/File-Path/lib:$PERL5LIB
export PERL5LIB=`pwd`/dist/PathTools:$PERL5LIB
export PERL5LIB=`pwd`/dist/PathTools/lib:$PERL5LIB
export PERL5LIB=`pwd`/ext/File-Find/lib:$PERL5LIB
Even so, I'll still get an error for a module that isn't even present in the 5.24.0 source!
Can't locate ExtUtils/MakeMaker/version/vpp.pm in #INC (you may need to install the ExtUtils::MakeMaker::version::vpp module) (#INC contains: <removed from post>) at (eval 2) line 2.
BEGIN failed--compilation aborted at (eval 2) line 2.
Compilation failed in require at .../perl-5.24.0/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 10.
BEGIN failed--compilation aborted at .../perl-5.24.0/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 10.
Compilation failed in require at Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.
Unsuccessful Makefile.PL(cpan/Archive-Tar): code=512 at make_ext.pl line 517.
make: The error code from the last command is 2.
I have MakeMaker, but the 5.24 version does not contain vpp.pm! Again, in desperation I attempted to put it in there from a different source, and I get this error:
LIBPATH=.../perl-5.24.0 ./miniperl -Ilib make_ext.pl cpan/Archive-Tar/pm_to_blib MAKE="make" LIBPERL_A=libperl.a
readdir(./../../../../../../..): No such file or directory at .../perl-5.24.0/ext/File-Find/lib/File/Find.pm line 142.
Can't cd to : No such file or directory
Unsuccessful Makefile.PL(cpan/Archive-Tar): code=512 at make_ext.pl line 517.
make: The error code from the last command is 2.
All of this makes me feel like perhaps I'm not configuring something right... Can anyone with some experience help me out with some cut and dry installation instructions for Perl on AIX? I'd be super grateful. Thanks!
Below is some information about my system:
> prtconf
System Model: IBM,8231-E1D
Machine Serial Number: Not Available
Processor Type: Not Available
Processor Implementation Mode: POWER 7
Processor Version: PV_7_Compat
Number Of Processors: 0
Processor Clock Speed: Not Available
CPU Type: 64-bit
Kernel Type: 64-bit
Memory Size: 10240 MB
Good Memory Size: Not Available
Platform Firmware level: Not Available
Firmware Version: IBM,AL770_092
Console Login: disable
Auto Restart: true
Full Core: false
I pull down and compile openssh and openssl frequently. I use gcc and no real magic that I can recall.
Here is my script to build it. I don't know which perl is native to AIX but it seems to work for me.
https://github.com/pedz/aix-build-scripts/blob/master/build-scripts/build-openssl

"Source file is more recent than executable" except it isn't

GDB is complaining that my source file is more recent than the executable, and it appears the debugging information is indeed related to an older version of the source file, because gdb is stopping on a blank line:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) up
#1 0x00007ffff7ba2d88 in CBKeyPairGenerate (keyPair=0x602010) at library/src/CBHDKeys.c:246
warning: Source file is more recent than executable.
246
(gdb) list
241 if (versionBytes == CB_HD_KEY_VERSION_TEST_PUBLIC
242 || versionBytes == CB_HD_KEY_VERSION_TEST_PRIVATE)
243 return CB_NETWORK_TEST;
244
245 return CB_NETWORK_UNKNOWN;
246
247 }
248
249 uint8_t * CBHDKeyGetPrivateKey(CBHDKey * key) {
250
But the executable is more recent than the source file, see here:
$ ls -l library/src/CBHDKeys.c
-rw-r--r-- 1 matt matt 9249 Apr 29 22:40 library/src/CBHDKeys.c
$ ls -l bin/noLowerAddressGenerator
-rwxr-xr-x 1 matt matt 17845 Apr 30 15:52 bin/noLowerAddressGenerator
I tried rebuilding after make clean and ccache -C but the same problem occurs. When I updated the source file I only added whitespace, so the program logic remains equal.I feel that has something to do with it, but since I cleared the ccache and cleaned the build and bin directory with make clean I'm not sure what is going on.
Versions:
GNU Make 3.81
gcc (Debian 4.8.2-16) 4.8.2
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
ccache version 3.1.9
SolydXK - SMP Debian 3.13.5-1 (2014-03-04)
Perhaps you're not using the most recent compiled version of the code, if it's in a shared library. You could use ldd noLowerAddressGenerator to see the library dependencies of your program; I don't know if it's possible from within GDB to locate the relevant library, but there ought to be a way (please comment or edit if you know how).
If this is indeed the case, you might want to set environment LD_LIBRARY_PATH in GDB prior to running the program, to place your newly-built library ahead of any installed ones. You could look into setting the RPATH ELF variable when linking, but that's likely to be less help.
Another possibility is to run your debugger on a system where you know the library isn't installed. I've had good results using schroot to keep build/debug/install environments separated.

Resources