Building gcc-4.1.2 on Fedora 17 (32-bit) VM - gcc

I'm working with some legacy hardware, and I need to compile a customised version of opensslv0.9.8e onto a 32-bit system.
My Fedora 17 VM comes with gcc-4.7.2. Unfortunately, compiling the openssl version with this doesn't work, I get illegal instruction errors. I found posts here and here that suggest that this version of openssl doesn't compile with gcc 4.2.0 or higher
when compiling openssl 0.9.8e with gcc 4.2.0, some errors show up (see
below). The test suite then fails with "instruction error". (The resulting
programs also fail.)
I built and checked gcc-4.1.2 on the system where the reported error arose.
I then rebuilt openssl with gcc-4.1.2 and could successfully run the test
suite.
My current plan is to build 4.1.2 onto my system. Unfortunately, when doing so, I run into the following error:
WARNING: 'makeinfo' is missing on your system. You should only need it if you modified a '.texi'
or a '.texinfo' file, or any other file indirectly affecting the aspect of the manual. The
spurious call might also be the consequence of using a buggy 'make' (AIX, DU, IRIX). You might
want to install the 'Texinfo' package or the 'GNU make' package. Grab either from any GNU archive site
Then,
make[3]: ***[fastjar.info] Error 1
make[3]: Leaving directory '/home/charles/build/make/fastjar'
. . .
make: *** [all] Error 2
I've installed texinfo, but I can't find gmake on the yum package manager.
What are the next steps I should take? I'm stumped at the moment ):

Related

conflicting types for '__readlink' during make glibc 2.14

I made a softwareupdate on a simulationsoftware which needs a newer version of glibc. Therefore I wanted to install the glibc version 2.14 on a new prefix.
According to How to upgrade glibc from version 2.12 to 2.14 on CentOS?
i tried to install it on a sles11sp3
mkdir /var/mpi/Libraries/glibc_install; cd /var/mpi/Libraries/glibc_install
wget http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.gz
tar zxvf glibc-2.14.tar.gz
cd glibc-2.14
mkdir build
cd build
../configure --prefix=/var/mpi/Libraries/glibc-2.14
make -j4
During the make I get the following error:
readlink.c:26: error: conflicting types for ‘__readlink’
../include/unistd.h:120: error: previous declaration of ‘__readlink’ was here
make[2]: *** [/var/mpi/Libraries/glibc_install/glibc-2.14/build/io/readlink.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/var/mpi/Libraries/glibc_install/glibc-2.14/io'
make[1]: *** [io/subdir_lib] Error 2
make[1]: Leaving directory `/var/mpi/Libraries/glibc_install/glibc-2.14'
make: *** [all] Error 2
Do you have a clue how to solve this problem?
io/readlink.c is just a stub implementation which always fails at run time. It is not supposed to be compiled at all when building for GNU/Linux. Instead, the implementation should come from the generic system call wrapper in sysdeps/unix/syscalls.list:
readlink - readlink i:spi __readlink readlink
However, recent Linux architectures (those called generic in Linux parlance, currently aarch64, csky, nios2, and riscv) no longer have a readlink system call, and the function as to be implemented using readlinkat. This implementation is in the file sysdeps/unix/sysv/linux/generic/readlink.c.
It's not clear what you are doing so that the wrong file is compiled. Are you sure you have installed compatible kernel headers?
The particular upstream commit (which went into glibc 2.15):
commit 95b7042bac3e2cfc6fef7aec6acc7d46dd50eba5
Author: Roland McGrath <roland#hack.frob.com>
Date: Fri Nov 11 10:02:42 2011 -0800
Fix __readlink declaration.
But given the fundamental nature of the build problem you encountered, I doubt that applying this patch, while addressing the immediate build failure, will give you a functional glibc build in the end.
GLIBC : 2.14 → 2011-06-01. The "bugfix version" 2.14.1 → 2011-10-07 https://ftp.gnu.org/gnu/glibc/
Note : make -j4 is not recommended for glibc, as far as I remember.
My tests (old SLE11 SP2) : The SLE 11 SP2 gcc 4.3.2 is too old for glibc-2.14.1, may be the SP3 minor gcc update (to 4.3.4) is also too old?
Using the "extra EL 6 gcc-4.9.3" .... for glibc-2.14.1 :
cd build-glibc214/ # the recommended build directory outside the glibc source
export CC=gcc49 CXX=g++49 && ../glibc-2.14.1/configure --prefix=/opt/glibc214
make # no errors
# make install # OK
Extra gcc´s : how to install gcc 4.9.2 on RHEL 7.4

GCC ld: can't find -lcurses

I'm trying to use make install, and I get error:
cannot find -lcurses
In my /usr/lib/curses/ I have two files: libcurses.so and libcurses.a.
So I do have that library, gcc just doesn't see it. I've read almost everything I can find but still couldn't make this work.
Any help would be appreciated.
This is output:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
collect2: error: ld returned 1 exit status
Makefile:125: recipe for target 'samtools' failed
make: *** [samtools] Error 1
Note: I've read every similar topic on this website, so please, don't mark this as duplicate.
The linker says:
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: \
skipping incompatible /usr/lib/libcurses.so when searching for -lcurses
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lcurses
You are performing a 64-bit build, but the the only libcurses.so the linker
can find is 32-bit, so it is skipped.
It is unclear from your several postings how this 32-bit /usr/lib/libcurses.so got
there. The official latest openSUSE
curses runtime package is libncurses5-5.9-53.4.x86_64.rpm. The official latest developent package is ncurses-devel-5.9-53.4.x86_64.rpm.
If you install either of these packages, they do not place any 32-bit binaries under /usr/lib, so I surmise
that your /usr/lib/libcurses.so got there in some unorthodox way.
Delete this /usr/lib/libcurses.so. Install the ncurses-devel rpm from your distribution's package manager,
e.g.zypper install ncurses-devel. To make sure you have done it successfully, check that /usr/lib64/libncurses.so exists afterwards.
Then in your makefile change:
LIBCURSES= -lcurses
to:
LIBCURSES= -lncurses
You will find that this change is described in paragraph 3 of the samtools INSTALL file.
You need a development library for ncurses installed, i.e., ncurses-devel (for SuSE).
Without the development library, the shared libraries for ncurses are only present as runtime files.
The ncurses development package installs files or symbolic links to make these options work: -lcurses, -lncurses (since the former is standard). It also installs the file to make -lncursesw link, but OP is not using that.
That message
skipping incompatible /usr/lib/libcurses.so
makes it seem as if OP copied files from some other system rather than installing OpenSuSE packages.
The extra question in SuperUser (GCC ld: can't find -lcurses) gives more information, but not enough to see why the file /usr/lib/libcurses.so is incompatible. It may be conflicting with the development package, however.

Which compiler settings should be used to compile Pantheios in current OSX?

Pantheios INSTALL.TXT says:
Open a command shell in the appropriate directory that matches your compiler: ...
My compiler is Clang:
> gcc --version
Apple LLVM version 5.1 (clang-503.0.40) ...
Target: x86_64-apple-darwin13.3.0
Which of the compiler settings files in Pantheios 1.0.1-beta214 is the most appropriate?
You can use homebrew to install an older version of gcc (e.g., gcc-4.2) and use the matching Pantheios makefile, like this:
brew install gcc42
make CC=gcc-4.2
However, as far as I have been able to tell, Pantheios is not going to be buildable on a recently-updated system. For example, as of today, building on OSX looks like this:
04:29:23 ~/src/pantheios-1.0.1-beta214/build/gcc42.unix$ make CC=gcc-4.2
Ensuring all STLSoft C source files are in UNIX format
sed: RE error: illegal byte sequence
make: *** [/Users/username/src/stlsoft-1.9.118/include/stlsoft/internal/dos2unix.has.been.performed] Error 1
I have also tried building on Windows as recently as 6 months ago and lost a good bit of time on it before giving up.
The library hasn't been updated in a very long time and the author has very little online activity since then. I call that "abandoned software". Building will very likely require a non-trivial amount of work on your part. I'd highly recommend severing the dependency on STLSoft if you do because it also appears to be abandoned.

Having Open MPI related issues while making CUDA 5.0 samples (Mac OS X ML)

When I'm trying to make CUDA 5.0 samples an error appears:
Makefile:79: * MPI not found, not building simpleMPI.. Stop.
I've tried to download and build the latest version of Open MPI reffering to Open MPI "FAQ / Platforms / OS X / 6. How do I not use the OS X-bundled Open MPI?" page and it did not solve the error.
make -j 4 2>&1 | tee make.out
[ lots of output ]
make[2]: *** [mpi/man/man3/MPI_Comm_disconnect.3] Error 127
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
I'm realy confused for now I have no idea what to do.
As mentioned in the comments, the simpleMPI example can be effectively bypassed by using make -k, or else deleting the simpleMPI subdirectory altogether, or renaming the Makefile that is in that directory. However if it is desired to actually install a version of MPI on the mac so as to be able to build the simpleMPI example, these instructions should help:
The issue here is that you don't have the MPI compiler installed. You will need to install the MPICC compiler for Mac OSX. These instructions will use the MPICH2 version of MPI, which is generally available here
Direct link to MPICH2 1.4 download
You can follow these instructions to build and configure MPICH2 for Mac OSX. In the configure step, also add --disable-f77 and --disable-fc:
./configure --enable-shared --enable-sharedlibs=osx-gcc --enable-fast=all --prefix=/usr/local/mpich2-optimized --disable-f77 --disable-fc
Then follow the guide instructions to make and then make install
Now create symbolic links to MPICC so you can build CUDA MPI easily
sudo ln -s /usr/local/mpich2-optimized/mpicxx /usr/bin/mpicxx
sudo ln -s /usr/local/mpich2-optimized/mpic++ /usr/bin/mpic++
Alternatively, another option is to add
/usr/local/mpich2-optimized/bin
to your path.
Now when making simpleMPI, it will properly build.
Or just install using MacPorts. The command is
sudo port install mpich
This will also make it easier to update in future since they host the latest version.
Or just install using Homebrew. The command is
brew install mpich2
I could compile all the CUDA samples after installing mpich through homebrew.

Building GCC cross compiler (from "Linux" to "Windows")

I want to build "gcc cross-compiler" to compile "c/c++" applications on "Linux" environment but for "Windows" target.
I have made this so far:
Installed the necessary tools and packages for building GCC listed on "Prerequisites for GCC" page.
Downloaded required sources:
"gcc-core-4.4.1", "gcc-g++-4.4.1", "binutils-2.19.1", "w32api-3.13-mingw32", "mingwrt-3.16-mingw32"
Created this directory hierarchy:
"${HOME}/gcc/" - for final cross-compiler
"${HOME}/src/" - for sources
"${HOME}/src/build-binutils/i386-mingw32/" - for building binutils to "i386-mingw32" target
"${HOME}/src/build-gcc/i386-mingw32/" - for building gcc to "i386-mingw32" target
Builded binutils package:
cd "${HOME}/src/build-binutils/i386-mingw32/"
../../binutils-2.19.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --disable-nls
make
make install
Copied "w32api" and "mingwrt" headers to the install directory:
cp -R "${HOME}/src/w32api-3.13-mingw32/include" "${HOME}/gcc/i386-mingw32"
cp -R "${HOME}/src/mingwrt-3.16-mingw32/include" "${HOME}/gcc/i386-mingw32"
And now when I am trying to build the "c (only) cross-compiler":
cd "${HOME}/src/build-gcc/i386-mingw32/"
../../gcc-4.4.1/configure --prefix="${HOME}/gcc" --target=i386-mingw32 --enable-languages=c --with-headers="${HOME}/gcc/i386-mingw32/include" --disable-nls
make<br>
it was building something about 4 minutes and then gives me these errors:
${HOME}/gcc/i386-mingw32/bin/ld: dllcrt2.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[2]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32/i386-mingw32/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `${HOME}/src/build-gcc/i386-mingw32'
make: *** [all] Error 2
From that error message I really don't know what to do now :-((( .
Does anybody know where is the problem?
Thanks.
That's actually OK: the way things go, you need to
build binutils
install headers
build the a partial C compiler: enough to create object files, but not enough to link
build the win32api and mingw runtime (which includes your missing dllcrt2.o)
build a complete C compiler (and other front-ends, such as C++, Fortran, Ada, whatever, if you want them)
You have successful performed step 3 above; it fails building libgcc (which is a GCC support library), but that means the C compiler core is functionnal (although it won't be able to link, it can still create valid object files). You can check that by looking at the gcc/xgcc file in your GCC build directory.
So, you need to go to the next step, not worrying about your current failure.
(To actuall install the partial C compiler, you should run make with the -k option, to have it do it best, even in the face of errors. For example, use make -k install.)
There are precompiled cross-compilers of MinGW-w64 available.
This allows to compile native 32- and 64-bit Windows binaries from Linux, a two minute tutorial is available at http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/
Just in case you don't want to spend a lot of time trying to build it yourself.
I grepped through the MinGW sources, and found that dllcrt2.o is something built off the mingwrt package. I assume you have to compile and install that, not just copy the headers?

Resources