In order to compile an old-compiler I am using the gcc that is installed in my machine (gcc version 4.4.6).
The gcc v 4.4.6 compiler isn’t supporting some syntaxs that are in the old-compiler files and is issuing errors like : lvalue required as left operand, error: attempt to use poisoned...and so on.
the last time someone has compiled that old compiler they used gcc version 2.96.
So I downloaded some older version of gcc (3.0 – didn’t found 2.96) and try to build binaries from it.
However – my machines are x86_64 and the 3.0 compiler issuing an error :
Configuration x86_64-redhat-linux-gnu not supported
naturally - no x86_64 existed way back in those days.
any advise will be welcome.
update :
I have installed on vertualBox an old redhat version (5.7) that came with an old gcc compiler (3.4.6) and tried to compile the cross compiler.My host is - i386-redhat-linux. Now , I didn't get this message and the compilation of the cross compiler started, BUT, when it came to compile unwind-dw2.c file I got the next assembler error :
/tmp/ccAk3sX0.s: Assembler messages:
/tmp/ccAk3sX0.s:259: Error: unrecognized instruction `addi r11,low(r0,.L47),r11'
/tmp/ccAk3sX0.s:736: Error: unrecognized instruction `addi r3,low(r0,.L327),r3'
/tmp/ccAk3sX0.s:1226: Error: unrecognized instruction `addi r3,low(r0,.L317),r3'
/tmp/ccAk3sX0.s:1739: Error: unrecognized instruction `addi r3,low(r0,.L412),r3'
So I am stuck again ...
Install a really old Linux distribution in a virtual machine.
In your case it's easier to install old distribution than to to ply with the current one.
But if you have plenty of time you can try to find and install all needed dependencies. By the way risking with stability of current OS installation.
Related
I'm using Mac to compile "rewritersample.cpp" from https://github.com/eliben/llvm-clang-samples/tree/master/src_clang with clang and I get the following error,
fatal error: 'clang/AST/ASTConsumer.h' file not found
I don't know why I'm getting this error even though I have clang installed on my Mac.
I was getting the same error and I fixed it by installing the libclang-dev library for the version of clang/llvm I was using.
On Linux with LLVM version 5.0 that was (not sure what the command is on a mac - sorry):
sudo apt-get install libclang-5.0-dev
Note that the documentation suggests that these examples are designed to be run with a version of llvm/clang that you have built from source (either by downloading a tarred release or cloning the llvm repository). I was able to get them to build exclusively from a version of LLVM and Clang I installed via my package manager. I had to set the configuration variables for the Makefile as follows:
CXX := /usr/bin/clang++
LLVM_SRC_PATH := /usr/lib/llvm-5.0
LLVM_BUILD_PATH := /usr/lib/llvm-5.0/build
LLVM_BIN_PATH := /usr/lib/llvm-5.0/bin
Again, it's probably a little different on a mac, but hopefully this can help point you in the right direction.
I'm using gsrc to compile glibc in order to use multiple versions of it on my machine. I'm using debian and when I tried make -C pkg/gnu/libc install -j8 it just reports this error:
Segmentation fault make: *** [sysinstall-install] Error 1
Does anyone have ideas on what this could be?
I'm using debian and when I tried make -C pkg/gnu/libc install -j8 it just reports this error
You didn't tell how this libc has been configured. In any case, incorrectly installing GLIBC on a system is a very easy way to render your system un-bootable. This is not recommended for novices (and you appear to be a novice).
compile glibc in order to use multiple versions of it on my machine
See this answer on how that can be achieved.
The newest publicly available tcpslice version 1.2a1 (found on its github) has a bug where it expects 8 bytes for a time field but gets 16 (when in 64 bit). This leads to the error:
tcpslice: problems finding end packet of file ./abc1234.bin
I got my info for this error from: https://bugzilla.redhat.com/show_bug.cgi?id=485670
This led me to grab the updated version (1.2a3) from here and try compiling from source: http://pkgs.fedoraproject.org/repo/pkgs/tcpdump/tcpslice-1.2a3.tar.gz/. I think this is or close to the actual patch
HOWEVER, I couldn't ./configure this on my mac because it says (understandably) this:
checking build system type... configure: error: cannot guess build type; you must specify one
Not one to give up, and becuase I don't wnat to switch over to linux to continue deveolping my wrapper script, I tried to compile like this:
./configure --build=i686-pc-linux-gnu
This configured and make'd!!! However, its 32 bit which still gives the same error when I run the newly made tcpdump!!
Is this possible at all, and what other --build type can I use that is for x86_64 bit systems? No other --build types are compiling for me. I have no idea how to find acceptable build types, and am currently referenceing this: https://gcc.gnu.org/gcc-4.2/buildstat.html
EDIT: I tried Warren Young's suggestion here but libtoolize --force did not remake config.guess, so I manually downloaded the "newest" config.guess from the link on this page with curl. However, now ./configure says:
checking build system type... Invalid configuration `x86_64-apple-darwin15.4.0': machine `x86_64-apple' not recognized
configure: error: /bin/sh ./config.sub x86_64-apple-darwin15.4.0 failed
Am I screwed? Or can I sitll try a default x86_64 -build type (which I still cannot find):
checking build system type... Invalid configuration `x86_64': machine `x86_64' not recognized
configure: error: /bin/sh ./config.sub x86_64 failed
Welp, the answer was to manually download the newest config.guess and config.sub files from here: https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html and to overwrite the ones in the tcpslice directory.
However, the same problem still existed. There must be another reason the time issue is happening on the mac because this version of tcpslice worked fine on ubuntu on the same pcap.
Thanks to Warren Young's post in this question for guiding me in the right (though not successful) direction: Compiling tcpsplice on a 64-bit machine. Guess I'll be using ubuntu to finish my script!
I have problem using gcc/g++ after I changed the machine I use,
I installed gcc-4.9.2 in my previous machine, when I moved to the new machine, I copied gcc folder to the new machine.
When I try to use I get this error :
/data/obenchek/gcc-4.9.2/bin/g++: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by /data/obenchek/gcc-4.9.2/bin/g++)
I have already checked this question :
`GLIBC_2.11' not found
If it says right, the version of libc and g++ are not compatible , libc version :
/lib/libc.so.6
GNU C Library stable release version 2.4 (20090904), by Roland McGrath et al.
...
So I should reinstall gcc completely or there is a easier way to resolve this ??
I copied gcc folder to the new machine.
That's your problem: don't copy, install appropriate GCC package instead.
Most UNIX systems, including Linux, guarantee backward compatibility: a binary compiled on an older system continues to run on a newer one.
The reverse is not true: a binary compiled on a newer system often will not run on an older one. This is working "as designed".
In this particular instance, you copied GCC compiled with GLIBC-2.11 or newer to a machine that has GLIBC-2.10 or older. And that doesn't work.
When trying to compile glibc on ubuntu 10.10, x86_64, i get the error:
../misc/syslog.c: In function ‘__vsyslog_chk’:
../misc/syslog.c:123: sorry, unimplemented: inlining failed in call to ‘syslog’: function body not available
../misc/syslog.c:155: sorry, unimplemented: called from here
make[2]: *** [/home/daniel/src/b.c/misc/syslog.o] Error 1
Try this wiki about glibc build issues.
I just ran into the same issue but with 32-bit. When running the configure script, adding CFLAGS='-U_FORTIFY_SOURCE -O2' to the command line seems to work. You may need to add -mtune=i686 and -march=i686 in there too. But maybe not for 64 bit. The i686 seems to be another bug.
Whenever you want to rebuild something on Ubuntu that Debian already, you are almost always best of by starting with the original source package on Debian.
In this particular case you can start with this version from the Debian experimental branch. By using the source package, you ensure you have required build-dependencies and should minimize surprises.
Also, building in a chroot environment is a good way to do this and made easy by packages such as pbuilder and sbuild.
Edit: There are build logs but they don't contain one for amd64, presumably because the maintainers built on that locally. But you can look at i386, say, and see that it passed the error you had.