I don't want to install all as it consumes much space..
the following is what i'm sure is needed:
gcc, make python..
what else?
On the site, in their documentation on installing...
http://www.shogun-toolbox.org/doc/en/current/installation.html
Requirements
SHOGUN requires the standard linux utils like bash, grep, test, sed,
cut, ldd, uname gcc g++ and cat python (debian package: python2.4 or
python2.5) for the ./configure to work.
Optionally you will need atlas and lapack (debian packages
lapack3-dev, atlas3-headers atlas3-base-dev or atlas3-altivec-dev
atlas3-sse2-dev) installed. Note that atlas/lapack is only supported
under linux (high performance computing should be done under linux
only anyway). In case atlas/lapack is unavailable, don't worry most of
shogun will work without, though slightly slower versions are used.
To
enable Multiple Kernel Learning with CPLEX(tm) just make sure cplex
can be found in the PATH. If it is not found shogun will resort to
GLPK (if version at least 4.29 is found) for 1-norm MKL, p-norm MKL
with p>1 will work nonetheless.
To compile the C# interface you need to have the C# developer files
(debian package mono-utils) installed.
To compile the Lua interface
you need to have the Lua developer files (debian package lua)
installed.
To compile the Java interface you need to have the Java
developer files (debian package openjdk-6-jdk) installed.
To compile
the R interface you need to have the R developer files (debian package
r-base-dev) installed.
To compile the Ruby interface you need to have
the Ruby developer files (debian package ruby) installed.
To compile
the octave interface you need to have the octave developer files
(debian package octave3.0-headers) installed.
To compile the python
interface you need to have numpy version 1.x installed (debian package
python-numpy) installed.
Related
I recently compiled a perl script using "pp" (Perl Packager) on an x86 linux box running Manjaro. I had someone test it on their x86 Debian 10 box, but it wouldn't run.
He said that since Libperl.so has a dependence on glibc v2.29. Since his OS release only allows up to a v2.28, that it's preventing it from executing.
Is there a way for me to compile my script with my version of the libraries so it will run on any x86 linux machine?
I ran the following command to compile my code:
pp -o oag1025 oag1025.pl
I tried using some of the options outlined here, but I couldn't get anywhere:
http://perl.mines-albi.fr/perl5.8.5/site_perl/5.8.5/pp.html
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
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.)