I am testing a Linux-PAM installation with this test program. When the pam_ldap.so module is called, the test program application fails with a segmentation error. Looking at the /var/log/messages, I can red the following error message:
petalinux authpriv.err pam_test: PAM unable to dlopen(/usr/lib/security/pam_ldap.so): /lib/libc.so.6: version `GLIBC_2.28' not found (required by /usr/lib/libldap-2.4.so.2)
petalinux authpriv.err pam_test: PAM adding faulty module: /usr/lib/security/pam_ldap.so
The system is an embedded Linux running on a Zynq processor.
Can anyone help me understand the source of the problem?
Thank you.
Can anyone help me understand the source of the problem?
You linked libldap-2.4.so.2 against GLIBC-2.28 (or later).
But at runtime, the version of GLIBC is 2.27 (or earlier).
GLIBC supports backward compatibility (binaries built against earlier version of GLIBC continue to run on systems with newer GLIBC versions).
But it doesn't support "build on newer, run on older" compatibility.
Related
Recently, I have installed glibc-2.35 version on my Linux distribution, before I have glibc-2.27 version. After Installing I am not able to use latest version glibc as a default for compiling source code.
As a sample trail, I have successfully compiled sample program with the latest version glibc by using following command.
gcc sample.c -o out -Wl,--rpath=/usr/lib -Wl,--dynamic-linker=/usr/lib/ld-linux-riscv64-lp64d.so.1
Here, I am facing a big difficulty is how to set latest glibc as a default glibc so that I can compile source packages normally like .configure and make -j8 and make install.
Please help me to solve this issue. I am not aware of pathcelf stuff how to use exactly.
I am trying to upgrade my current Buildroot build from 2019.11 to the newest 2020.02 release. With 2019.11 everything builds and produces a bootable image.
With the 2020.02 release everything still builds, but the device no longer boots and does not output any booting messages (no log data and no out via serial).
The Issue seems to be, the binutils version. In 2020.02 binutils 2.30 is no longer supported and the min version is 2.31.1 (this is the only legacy option in my config when upgrading).
Is this a known issue? are there any workarounds?
When I try building the 4.14 Kernel the build aborts during Kernel compilation. This post encountered the same issues I had during the compilation of the 4.14 Kernel. So I guess a Kernel upgrade is not a solution.
Edit: The kernel version that does build but not boot is 4.4 .
Edit 2: The target hardware is a Dual-core Intel Atom (x86_64).
I am trying this on Windows: https://github.com/cfenollosa/os-tutorial/tree/master/01-bootsector-barebones
E:\Code\MyOS\os>D:\qemu\qemu-system-x86_64.exe boot_sect_simple.bin
WARNING: Image format was not specified for 'boot_sect_simple.bin' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
Unexpected error in aio_context_set_poll_params() at /home/stefan/src/qemu/repo.or.cz/qemu/ar7/util/aio-win32.c:413:
D:\qemu\qemu-system-x86_64.exe: AioContext polling is not implemented on Windows
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
This also gives the same error:
D:\qemu\qemu-system-x86_64.exe -drive format=raw,file=boot_sect_simple.bin
QEMU version:
E:\Code\MyOS\os>D:\qemu\qemu-system-x86_64.exe -version
QEMU emulator version 2.11.90 (v2.12.0-rc0-11704-g30195e9d53-dirty)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
NASM version:
E:\Code\MyOS\os>E:\Code\MyOS\nasm-2.13.03\nasm.exe -version
NASM version 2.13.03 compiled on Feb 7 2018
This is a bug in the (release-candidate rc0) version of QEMU you are using: https://bugs.launchpad.net/qemu/+bug/1761027
It was fixed in the final 2.12.0 release. So you should upgrade your QEMU (either to 2.12.0 or to the more recent 3.0).
In general it's a bad idea to run with release-candidate versions unless you're using them specifically to test them before a full release.
using: 4.2.8-200.fc22.x86_64
I have a lot of issues with installing latest package of fedora's lttng.
I have installed the latest version available for fedora as for 29/6/16.
Available Packages
Name : lttng-tools
...
Version : 2.6.0
whereas the latest available for other distributions is 2.8.0
http://git.lttng.org/?p=lttng-modules.git;a=shortlog;h=refs/heads/stable-2.8
as for fedora lttng-modules need to be installed manually.
none or the 2.5 through 2.6.1 are compiling.
error: implicit declaration of function ‘__get_cpu_var’
and 2.6.3 report
Can't read private key
for each module and reports
depmod: WARNING: /lib/modules/4.2.8-200.fc22.x86_64/extra/probes/lttng-probe-x86-exceptions.ko needs unknown symbol lttng_pid_tracker_lookup
none of the modules are available at insmod.
trying 2.8.0 modules result
reports
Error: Kernel tracer ABI version (2.1) is not compatible with expected ABI major version (1.*)
second attempt result with the following.
lttng (create, enable, start, stop, view) result with no results.
Is there any plans you guys know of for further support for fedora beyond 2.6?
any Ideas for how can I make lttng works for my 22 fedora.
(not upgrading to fedora 24 due to performance degradation )
Regards,
Nir.
I have recently taken over the maintenance of the lttng packages in Fedora, F25 will ship with the latest lttng 2.8 packages. As for F22, you best option would be to try to rebuild the F25 sources packages on F22. For the kernel modules you can use this source package intended for RHEL7 : http://packages.efficios.com/rhel/7/SRPMS/latest/lttng-modules/lttng-modules-2.8.0-1.el7.src.rpm
Hope it helps, cheers.
In attempting to install pkgin/pkgsrc (NetBSD-based package managment tools), using the saveosx.org instructions and github repository.
The repository has installation instructions, which I followed, up to the point of a specific but uninformative error:
It looks like there was an issue running: sudo /usr/pkg/bin/pkgin -y update
I tried running this file directly, but my terminal reports a segmentation fault.
I'm running OSX 10.7.5 and have Xcode-Command-Line Tools installed, but I find no information about Darwin version compatibility on NetBSD's site. My searches have revealed no one else reporting issues using pkgin.
Version 5.0+ is supported according to www.netbsd.org/docs/pkgsrc/platforms.html#darwin, which according to wikipedia (en.wikipedia.org/wiki/Darwin_%28operating_system%29#Release_history) corresponds to OSX 10.1.1+
What options do I have besides upgrading my operating system and hoping the problem is fixing by having newer libraries or a newer kernel?
For reference:
www.pkgsrc.org/#docs
www.perkin.org.uk/pages/pkgsrc-binary-packages-for-osx.html
wiki.netbsd.org/pkgsrc/pkgsrc_64bit_osx/
Related question: Unable to run pkgin on Mac OSX
It would appear that the pkgin binary currently supplied by saveosx is compiled only for more recent OSX releases. It needs at least a Darwin-14.x kernel, or newer, so it won't even run on 10.9.5. Unfortunately the script fails to check the OSX version before it blindly tries to run the pkgin binary, causing the program to crash.
saveosx is basically a painfully obnoxious, rather ugly, and poorly implemented. set of scripts that are superfluous to actually using pkgsrc on OSX.
I would strongly recommend avoiding saveosx for the time being.
Instead I would recommend trying the following well supported alternative:
OSX binary pkgsrc packages
A 32-bit Snow Leopard version that runs on 10.6.8 and newer is available, and I just checked the distribution directory and I see some 2015Q1 i386 packages are just now available, still supporting 10.6.8:
2015Q1 32-bit (i386) Snow Leopard and newer pkgsrc bootstrap
You can of course also build your own pkgsrc bootstrap for any specific OSX environment:
pkgsrc home