Is there a switch in objdump or readelf which can tell if an ELF binary was built on Redhat or SUSE? I only have binary and no source code.
Is there any other way (like strings command or nm) that could I could use if objdump/readelf isn't useful.
Unlikely. You may make a guess based on the required libraries from readelf -a /path/to/binary | grep -E '(NEEDED|#GLIBC_)' what the (highest) required glibc version is.
Maybe, in case there are enough strings left in the ELF binary, there is a hint if the used compiler is mentioned somewhere.
Related
Scenario:
$ echo "#include <uchar.h>" | gcc -xc - -std=c11 -pedantic -Wall -Wextra
<stdin>:1:10: fatal error: uchar.h: No such file or directory
compilation terminated.
$ gcc --version
gcc (GCC) 11.2.0
$ uname -a
CYGWIN_NT-10.0 xxx 3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin
Does is mean that C standard library does not support <uchar.h>?
UPDATE. From Brian Inglis:
Nobody else has noticed or mentioned those in the last decade, so there
may not be (any updates), as volunteers have limited time and their own interests and
priorities.
Given that newlib is a freestanding implementation, and gcc does not
provide that header, those definitions or declarations, these are
considered platform implementation issues, which someone supporting that
platform has to decide if they will provide and support.
ICU provides uchar.h which Cygwin libicu-devel maintainer installs under
/usr/include/unicode/ with Unicode licence under
/usr/share/icu//LICENSE.
You could pull those two files from the ICU distro for use in your work.
It also is/will be available on glibc platforms which support it.
Remember that GNU products are GPL licensed with possibly undesirable
requirements for most commercial products.
Similarly, TIME_UTC may not be available on some newlib
platforms/targets, so it will be up to platform and/or target
maintainers to decide if they can support it, and provide implementations.
I don't know what your host platform is, your newlib target, or what
POSIX time.h CLOCK_/clock_... support is available, but you may wish to
use that instead, until someone can provide the ISO C equivalent in
newlib under a BSD licence.
You may also wish to look at what is available in *BSD sources.
Install the libicu-devel package
the header will be under:
/usr/include/unicode/uchar.h
We have a Solaris 11 system with gcc 7.3, we need to install the Ada package. On Linux gcc 7 came with the Ada/GNAT as part of the gcc install:
apt install gcc
I visited AdaCore looks like Solaris (SPARC) is not longer on the list. I need to use Ada95 and we want the same compiler on both Linux and Solaris in any case.
pkg install gcc
Only installed various C++ commands and Fortran.
pkg install gcc-ada
And variants like gcc7ada, found nothing to install.
If must, we can rebuild the Ada component of GCC 7, however I haven't found a clear cood-book style "How To ..."for that (yet).
Hopefully you can point me to these items in order of preference to help us get back-on-track.
Solaris 11 gcc-ada package for gcc7/Solaris 11 spark, and the package repository.
An 'alternative' package repository were I can retrieve the GCC Ada tooling.
Pre-build GCC 7 Ada module that we can copy to the right places.
Ready-rolled Build Ada/GNAT project for Solaris and how to download and get start building.
Instructions to download and build gcc-ada with gcc 7 on Solaris (or Unix).
From th epast few days searching about on Gnu Compiler Collection, Oracle, the package manager searches, google and so forth ... It really seems like there's next to no support for CGG Ada on Solaris these days.
I very interested in other solutions beyond that list. For instance, has anyone cross-compiled from Linux to Solaris? Would that work with GDB on the Solaris machine anyway?
Looking forward to your suggestions.
I've successfully built gcc 7.50 (x86_64 native with i386 cross-compiler) with GNAT on OpenIndiana (Hipster 2020/10) using the following procedure.
Download the bootstrap compiler from Dragonlace at http://downloads.dragonlace.net/src/ada-bootstrap.x86_64.solaris.511.tar.bz2
Get the illumos gcc 7.5.0 source from https://github.com/illumos/gcc/tree/il-7_5_0
Put the bootstrap compiler's bin directory at the front of $PATH, replace /usr/bin/gcc /usr/bin/cpp /usr/bin/g++ with symlinks to their counterparts in the bootstrap compiler directory (see note below re g++ and c++)
Make sure you've got gnu-binutils and gmake; then run contrib/download_prerequisites
Configure with
--enable-languages='c ada c++' --build=x86_64-aux-solaris2.11 --enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib --with-gnu-as --with-as=/usr/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld
gmake and then gmake install
NOTES:
This setup should be close enough to Solaris 11 to work. If it doesn't, try using the regular gcc 7.5.0 release rather than the illumos-modified branch.
If you get stuck at a linking stage, try using a gcc ld, but you should definitely try to use the Solaris ld first. The gnu as (gas) makes the build go much more smoothly. I didn't have any problems, but if you get stuck at the end of stage 1 or the beginning of stage 2, try setting $CONFIG_SHELL=/usr/bin/ksh -- I think it has been fixed, but at least with older gcc releases one needed to specify ksh because the built-in sh had some non-POSIX peculiarities that didn't work with some of the components' makefiles
I couldn't get one of the support libs for gnat to compile easily without building gcc c++ and using g++ with a full bootstrap. You might be able to figure it out, but the path of least resistance is likely to build gcc c++ and put the g++ symlink in /usr/bin, which is where the makefile wanted to find it.
Please note that I don't know much about Solaris, but a quick search on Google gave me the website OpenCSW. This website provides the packages gcc4ada and gcc5ada.
It appears that gcc5ada is build using a makefile (as found here, in particular notice line 424). A similar makefile exists for gcc7ada (as found here, in particular notice line 426). However, while it seems that the package "gcc7ada" can be created with the latter makefile, it is not published on the OpenCSW.org website (website is no longer updated?).
You could try to install gcc5ada first and then use this old GCC/GNAT compiler as a bootstrapper for compiling the required version (using the GCC 7 makefile).
I work for buildroot. My purpose work GUI on my buildroot with Gtk3.0 and Gstreamer1.0. I use Olinuxino A13 so I wrote GUI code(Gtk3.0 hello world example) on this with codeblocks. I use Debian wheezy. I want transfer this code from Debian wheezy to buildroot.
I tried this:
I transferred /path_to_proectfile/bin/Debug/my_program.my_program created by codeblocks. I wrote ./my_program on terminal and code work. I transferred this file to my buildroot but ./my_program does not work. It returns No such file or directory error.
I thought the problem might be compiling and tried compiled on terminal. I use gcc -o my_program main.c 'pkg-config --cflags --libs gtk+-3.0' again work on Debian wheezy terminal. After I transferred to buildroot but result does not change. I tried different compile kind like cc,arm-linux-gnueabi-gcc etc. but every time No such file or directory error.
Finally when I don't use gtk library(Just use printf Hello World), I saw Hello world. When I add gtk library returns No such file or directory error. Have you any suggestion?
You need to cross compile your program with the corresponding buildroot toolchain. It looks like you have transferred a binary which was built against a different libc (this gives a "No such file or directory" error).
The buildroot cross compiler with the correct libc can be used by setting CC to "path_to_buildroot_output/host/bin/arm-linux-*-gcc" (the exact name depends on which toolchain options you have chosen).
I have gcc 3.4.6 installed on sparc9 and sparc10 systems. I am having incompatibility issues when I try to use shared object(built on sparc9) on sparc10. I am not seeing any issue if I use same shared object on sparc9 system. Snippet from makefile:-
LIB=-L/usr/lib/sparcv9 -L/usr/local/lib/sparcv9 -L/lib/sparcv9
gcc -m64 -shared -fPIC -o myapi.so.1 myapi.o $(LIB) -lc -lstdc++ -luuid
Now following in sparc10:-
ldd -d /home/myapi.so
libstdc++.so.6 => /usr/local/lib/sparcv9/libstdc++.so.6
symbol not found: _ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode (./myapi.so)
I have skipped other dependencies in above output which appear normal.
Then, I ran "nm" against libstdc++.so.6 in /usr/local/lib/sparcv9 for above unreferenced symbol and came with following conclusion:-
V9---> _ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode
V10--->_ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode
If you look carefully, you can see a difference in mangled-name symbol in sparc9 and sparc10... "ExSt12" v/s "ElSt12".
Similarly, if I build myapi.so on sparc10, it fails on sparc9 because of symbol mismatch in V9 and V10.
Can someone please point me to any helpful hints as to if I am missing something? Or do I need to install any package on V9. I am assuming that shared object built on V9 should work on V10.
I would like to add that there is a size of libstdc++.so.6 on V9 is different from V10. V9 has SMCgcc and V10 has both SUNWgccruntime and SMCgcc.
Those symbols demangle as:
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode)
and
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode)
Notice that one uses long and the other uses long long
I suspect that means one was built with 64-bit file offsets (aka large file support) and the other wasn't. That means the two versions of GCC have been built differently (by sunfreeware.com or whoever provided them) and are incompatible.
Looks like you're using incompatible versions of the GNU C++ compiler & standard library on the two OS'es. Unfortunately, there is no standard ABI for C++ and many compilers change symbol mangling conventions incompatibly between major releases (such as Sun C++ compiler 4.x vs. 5.x, or g++ 2.x vs. 3.x vs. 4.x).
The /usr/local/lib path implies you're using the libraries from the SMCgcc packages downloaded from the sunfreeware.com site - make sure you have matching versions on the Solaris 9 and 10 machines. (There is no "sparc 10", so you must mean Solaris 10.)
I'm using a Perl script to modify some files inside a .tar, and the directory structure inside the resulting .tar disappears.
Eliminating more and more code I've come as far as all that's required to reproduce this is
my $data_tar = Archive::Tar->new('data.tar');
$data_tar->write('modified_data.tar');
Both .tar-files have all the files, however the indication of what directories the files and subdirectories were located in are lost.
I've looked through the docs and src for Archive::Tar but I really don't understand what's going on.
I'm using perl 5.10.0 on win32, tar 1.12 and Archive::Tar 1.54.
I examined the .tar-files in an editor and the data.tar contains dir/ and dir/file.txt, but in the modified_data.tar they show up as dir and file.txt so my original tar seems ok.
Anyone of you that have seen this before or have any ideas?
C:\Temp> perl -v
This is perl, v5.10.1 built for MSWin32-x86-multi-thread
(with 2 registered patches, see perl -V for more detail)
C:\Temp> perl -MArchive::Tar -e "print $Archive::Tar::VERSION"
1.52
Cannot replicate using data.tar created with:
C:\Temp> tar --version
tar (GNU tar) 1.21
As #~quack notes, the docs state:
Note that GNU tar earlier than version 1.14 does not cope well with the POSIX header prefix. If you use such a version, consider setting the $Archive::Tar::DO_NOT_USE_PREFIX variable to true.
I tried your script but could not reproduce the problem (on FreeBSD using Perl 5.10).