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.)
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
I can't find any documentation whatsoever on how to target 32-bit with Red Hat Developer Toolset (version 9.0 in this case running on CentOS 7). The release notes mention:
Generation and manipulation of 32-bit binaries is also supported
It also ships the needed 32-bit libraries in:
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/
However, building fails. Example trying to build a minimal int main() {} program:
$ scl enable devtoolset-9 'g++ -m32 tst.cpp'
/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: skipping incompatible /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++_nonshared.a when searching for -lstdc++_nonshared
/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: cannot find -lstdc++_nonshared
collect2: error: ld returned 1 exit status
The library it fails to find actually exists though:
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a
No amount of -L flags fixes it (and it would be the wrong solution anyway; the linker should not even be attempting to load 64-bit libraries in -m32 mode.)
What am I missing here?
I guess you didn't notice that /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a is quite likely a dangling symlink:
$ file /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++_nonshared.a: broken symbolic link to `../../../i686-redhat-linux/9/libstdc++_nonshared.a'
$
The destination file /opt/rh/devtoolset-9/root/usr/lib/gcc/i686-redhat-linux/9/libstdc++_nonshared.a is however unfortunately not provided by any CentOS package (but it should be in devtoolset-9-libstdc++-devel.i686). Thus it's likely a CentOS-specific packaging mistake as RHEA-2019:4134 provides the questioned package devtoolset-9-libstdc++-devel-9.1.1-2.6.el7.i686.rpm for Red Hat Enterprise Linux 7 including the desired file (explicitly verified by yum install /opt/rh/devtoolset-9/root/usr/lib/gcc/i686-redhat-linux/9/libstdc++_nonshared.a on RHEL 7).
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 was trying to build only gcc using yocto. I tried with "bitbake-layers show-recipes" it was showing multiple recipes for gcc, similarly for bitbake -s.
#bitbake-layers show-recipes
gcc:
meta 4.8.2
gcc-cross:
meta 4.8.2
gcc-cross-canadian-arm:
meta 4.8.2
gcc-cross-initial:
meta 4.8.2
gcc-crosssdk:
meta 4.8.2
gcc-crosssdk-initial:
meta 4.8.2
gcc-runtime:
meta 4.8.2
gccmakedep:
meta 1:1.0.2
#bitbake -s
gcc :4.8.2-r0
gcc-cross :4.8.2-r0
gcc-cross-canadian-arm :4.8.2-r0
gcc-cross-initial :4.8.2-r0
gcc-crosssdk :4.8.2-r0
gcc-crosssdk-initial :4.8.2-r0
gcc-runtime :4.8.2-r0
gccmakedep 1:1.0.2-r3
Please guide me to understand why there are multiple recipes related to gcc and which one I have to build.
In yocto, is there one to one match for recipe and package. i.e for creating each package there is a corresponding only one recipe?
To explain each one in turn:
gcc is the recipe for gcc that runs on the target machine itself.
gcc-cross is the cross-compiler that the build system uses. If you build any recipe for the target that needs to be compiled with gcc, this is what will be used to compile that.
gcc-cross-canadian- is the final relocatable cross-compiler for the SDK, in this case for the ARM architecture.
gcc-crosssdk is an intermediate step in producing gcc-cross-canadian.
the *-initial are the initial versions of the compiler required to bootstrap the toolchain separately for the standard cross-compiler and for the SDK.
gcc-runtime builds the runtime components that come as part of gcc (e.g. libstdc++).
gccmakedep isn't really part of gcc itself, it's a script that comes as part of the X11 utilities that some projects need to determine dependencies for each source file.
When you say "you only need to build gcc", it's not entirely clear what you mean, but I suspect it's either gcc for the target (in which case it's "gcc", though I suspect you'll probably need more than that - packagegroup-core-buildessential may be what you want) or you want a cross-compiler you can install separately in which case you probably ought to bitbake meta-toolchain or bitbake -c populate_sdk imagename. That'll contain more than just gcc but it's likely gcc alone isn't going to be enough anyway.
GCC is a huge project. Maybe this recipe could help you understand GCC and Yocto a little bit better. The following information is some information paraphrase from "Embedded Linux Projects Using Yocto Project Cookbook" by Alex Gonzalez
GNU toolchain contains the following components:
Assembler (GNU as): part of the binutils package
Linker (GNU Id):
part of the binutils package
Compiler (GNU gcc): support for C, C++,
Java, Ada, Fortran, and Objective C
Debugger (GNU gdb): GNU debugger
Binary file tools (objdump, nm, objcopy, readelf, strip, and so on):
these are part of the binutils package
These components are enough to build bare metal applications
bootloaders like u-boot, Linux Kernel because they do not need C
library and they implement C library functions they need.
POSIX-compliant C library is needed for LInux user space applications.
glibc is the default C library used in the Yocto Project.
On Embedded Systems, we need a cross-compilation toolchain. We build
in a host computer but run the result binarines on the target which is
usually different architecture. There are several types of toolchains
based on build machine, target machine.
The most common combinations are:
Native: An example of this is an x86 machine running a toolchain that >has also been built on an x86 machine
producing binaries to run on an x86 machine. This is common in desktop
computers.
Cross-compilation: This is the most common on embedded
systems; for example, an x86 machine running a toolchain that has also
been built on an x86 machine but producing binaries to run on a
different architecture, like ARM.
Cross-native: This is typically the
toolchain running on targets. An example of this is where a toolchain
has been built on an x86 machine but runs on ARM and produces
Canadian: Rarely seen, this is where the build, host, and target
machines are all different.
I'm trying to install Bugzilla but encounter a Perl problem.
When installing required Perl modules, I get the following error message:
ERROR: Using install-module.pl requires that you install a compiler, such as gcc.
gcc 4.2.3 is installed and in the path. I'm using perl v 5.8.6 OS: Linux DiskStation 2.6.32.12
Another thread on Stackoverflow refers to PerlGcc but it seems to work on Solaris only.
How can I make Perl find gcc?
I'm guessing you're talking about this thread. Assuming that the guy talking about the version of gcc being relevant was onto something, could you check that you don't have an older version of gcc lying around somewhere higher in the path with
$ which gcc