I have 64 bit solaris - sparc and opteron systems. Under /usr/local/lib , I can see libiconv.so for both systems. The file command on libiconv.so gives following output:-
ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available
How do I build 64 bit libiconv w/o disturbing existing 32 bit on both sparc and opteron systems? Reason being, I am not aware of existing version of libiconv.
This libiconv.so is not part of the OS being in the non standard /usr/local/lib. Should you want to build yourself or install from elsewhere a 64 bit version of this library, you would install it in /usr/local/lib/amd64 or /usr/local/lib/64.
However, this is probably useless in the first place as Solaris already includes the iconv library function in its standard C library so Gnu libiconv is basically redundant and unnecessary here.
Related
I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).
First Question: What is the best way to support various 'standard' Linux platforms with a single C++11 binary?
This binary uses a handful of third party libraries including boost, zlib, xml2, openssl (all of which
I can build statically).
The binary must run on a variety of Linux platforms for x86_64: Ubuntu 16.04 and 14.04, Centos 7.2 and Debian.
Soon it must run on Darwin x86_64 and Ubuntu 16.04 on a Beagle Bone Black.
The default versions of compilers, libstdc++ and libc runtimes vary quite a bit on these platforms.
I have had some Linux success building on Ubuntu 14.04 with an upgraded (toolchain r-test) g++ 5.3 compiler
using these compiler options (note not using the "-static" switch):
-static-libstdc++ -static-libgcc -D_GLIBCXX_USE_CXX11_ABI=0
However, this requires installing the upgraded 5.3 compiler on the host (default is 4.9 IIRC) and
some runtime libs on the target platforms which is not preferred and risks issues with libc.so.
If it should be determined that this sort of solution is best, then I would prefer to build on
16.04 with the newest g++ or clang with switches so the binary runs on older platforms with
minimal changes to defaults. Yes, I know I am perhaps asking for the moon :)
Second question: instead of one binary, maybe one compiler and libc for all platforms including Darwin and Windows?
I was also considering an attempt to use musl to create a 'more consistently behaved binary. I could consider using clang instead of g++.
Anyone with experience/recommendations? I would very much like to avoid maintaining
separate compilations and combinations of third-party libs and compilers and settings and upgrades for each platform (especially for Linux targets but pretty typical for different operating systems).
Using the same version of the same compiler and possibly the same version of a libc would be best
but may not be possible: clang with musl?
Thanks
I need gcc installed on cygwin,
but when I search for gcc in the cygwin setup application, I get several results with the string "gcc" in their names, for example:
cygwin32-gcc-ada
cygwin32-gcc-core
cygwin32-gcc-fortran
cygwin32-gcc-g++
cygwin32-gcc-objc++
...
gcc-ada
gcc-core
gcc-fortran
gcc-g++
...
libgcc1
minigw-gcc-core
minigw-gcc-g++
....
minigw64-i686-gcc-core
minigw64-i686-gcc-g++
...
when I am searching for gcc in synaptic in ubuntu, I have a very obvious result
what am I suppose to do with these names? install all?
install a random one and then create symlinks to where ever it's binary may land to /usr/bin/gcc ?
what usefulness and productivity can be achieved from these many packages names showing up when I attempt searching for that one gcc that I keep reading online that I need to build packages that aren't on cygwin installer?
everywhere I read about "install gcc on cygwin and then continue to do this and that" they never mention which of the gcc packages above is single correct one,
its like everyone everywhere somehow already knows which gcc is the correct one and that information is no where to be found online.
I would appreciate clarification and further help.
EDIT:
sometime in the past, there actually used to be a package called just "gcc",
I found that from the screenshots here:
http://www.eecg.utoronto.ca/~aamodt/ece242/cygwin.html
I can't tell how many years ago that was.
The things that make Cygwin GCC packages confusing are:
gcc-core and cygwinXX-gcc-core are confusingly related (XX is 32 or 64 depending on your Cygwin architecture).
There are packages for both MinGW and MinGW-w64, which are different projects, although many people are unaware of their coexistence (I was).
As of Oct 2015, Cygwin GCC packages are broken down like this.
In Cygwin x86 (32-bit):
PROJECT: Cygwin GCC (Windows POSIX-enabled executables via linking to cygwin1.dll)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
gcc-core x86 /usr/bin/gcc.exe
/usr/bin/cc (symlink)
/usr/bin/i686-pc-cygwin-gcc.exe (hard link)
cygwin64-gcc-core x86_64 /usr/bin/x86_64-pc-cygwin-gcc.exe
PROJECT: MinGW (Windows 32-bit standalone executables)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw-gcc-core x86 /usr/bin/i686-pc-mingw32-gcc.exe
PROJECT MinGW-w64 (fork from MinGW for building 64-bit)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw64-i686-gcc-core x86 /usr/bin/i686-w64-mingw32-gcc.exe
mingw64-x86_64-gcc-core x86_64 /usr/bin/x86_64-w64-mingw32-gcc.exe
In Cygwin x86_64 (64-bit):
PROJECT: Cygwin GCC (Windows POSIX-enabled executables via linking to cygwin1.dll)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
gcc-core x86_64 /usr/bin/gcc.exe
/usr/bin/cc (symlink)
/usr/bin/x86_64-pc-cygwin-gcc.exe (hard link)
cygwin32-gcc-core x86 /usr/bin/i686-pc-cygwin-gcc.exe
PROJECT: MinGW (Windows 32-bit standalone executables)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw-gcc-core x86 /usr/bin/i686-pc-mingw32-gcc.exe
PROJECT MinGW-w64 (fork from MinGW for building 64-bit)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw64-i686-gcc-core x86 /usr/bin/i686-w64-mingw32-gcc.exe
mingw64-x86_64-gcc-core x86_64 /usr/bin/x86_64-w64-mingw32-gcc.exe
The following are for compiling 32-bit binaries in 64-bit Cygwin:
cygwin32-gcc-ada
cygwin32-gcc-core
cygwin32-gcc-fortran
cygwin32-gcc-g++
cygwin32-gcc-objc++
...
The following are the main gcc pieces. If you don't need some of these specific languages, like Ada or Fortran, don't install them.
gcc-ada
gcc-core
gcc-fortran
...
This is a library required by gcc.
libgcc1
The mingw (not minigw...those appear to be typos) version are for compiling programs in Cygwin that do not depend on Cygwin1.dll. Programs built with these use the Microsoft C RTL, and can be installed on systems that don't have Cygwin. They also are not subject to Cygwin's rather restrictive Open Source License. The ones whose names do not contain 64-i686 are for producing 32-bit binaries, while the ones that do are for producing 64-bit binaries.
mingw-gcc-core
mingw-gcc-g++
....
mingw64-i686-gcc-core
mingw64-i686-gcc-g++
Note that you can see all of this information at http://cygwin.com/packages.
I have a 64-bit system, but gcc is 32-bits and when I do
>./gcc -c foobar.c
it makes foobar.o which is 64-bits. OK, but how does it know to do that? Based on what environment setting does it know to produce 64-bit object, and where is that documented??
Come to think about it, it is strange that it does that, is it not?? But file utility clearly says, gcc is 32 bits and foobar.o is 64 bits. ( I moved everything to the same directory so it would not be confused. )
I also checked the 3 dynamically linked libraries that it reads: libc, libm and libz and they are also all 32 bits.
To clarify, I don't want to know, how to make it do 32 bits. I want to know, what is it looking at now that it makes it do 64. That is my question, not how to force it the other way around.
When GCC is configured three different systems can be specified:
build: - the system where GCC is going to be built (probably not
relevant to your question)
host: - the system where GCC is going to
be executed (32 bit in your case)
target: the system where binaries, produced by GCC are going to be executed (64 bit in your case)
You can see how your GCC was configured by running:
gcc -v
command (look for --{build,host,target} options.
I've downloaded MinGW with mingw-get-inst, and now I've noticed that it cannot compile for x64.
So is there any 32-bit binary version of the MinGW compiler that can both compile for 32-bit Windows and also for 64-bit Windows?
I don't want a 64-bit version that can generate 32-bit code, since I want the compiler to also run on 32-bit Windows, and I'm only looking for precompiled binaries here, not source files, since I've spent countless hours compiling GCC and failing, and I've given up for a while. :(
AFAIK mingw targets either 32 bit windows or 64 bit windows, but not both, so you would need two installs. And the latter is still considered beta.
For you what you want is either mingw-w64-bin_i686-mingw or mingw-w64-bin_i686-cygwin if you want to compile for windows 64. For win32, just use what you get with mingw-get-inst.
See http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure for an explanation of file names.
I realize this is an old question. However it's linked to the many times the question has been repeated.
I have found, after lots of research that, by now, years later, both compilers are commonly installed by default when installing mingw from your repository (i.e. synaptic).
You can check and verify by running Linux's locate command:
$ locate -r "mingw32.*[cg]++$"
On my Ubuntu (13.10) install I have by default the following compilers to choose from... found by issuing the locate command.
/usr/bin/amd64-mingw32msvc-c++
/usr/bin/amd64-mingw32msvc-g++
/usr/bin/i586-mingw32msvc-c++
/usr/bin/i586-mingw32msvc-g++
/usr/bin/i686-w64-mingw32-c++
/usr/bin/i686-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-c++
/usr/bin/x86_64-w64-mingw32-g++
Finally, the least you'd have to do on many systems is run:
$ sudo apt-get install gcc-mingw32
I hope the many links to this page can spare a lot of programmers some search time.
for you situation, you can download multilib (include lib32 and lib64) version for Mingw64:
Multilib Toolchains(Targetting Win32 and Win64)
By default it is compiled for 64bit.You can add -m32 flag to compile for 32bit program.
But sadly,no gdb provided,you ought to add it manually.
Because according to mingw-64's todo list, gcc multilib version is done,but gdb
multilib version is still in progress,you could use it maybe in the future.
Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet -w64-mingw32.
gdb -- Native support is present, but some features like multi-arch support (debugging 32-bit and 64-bit by one gdb) are still missing features.
mingw-64-todo-list