configure: error: assembler too old, .cfi_personality support missing - installation

I have tried one day to install glibc-2.11 for sublime text.
My system is centoS 5.5 64, every time I attempted to install glibc-2.11, it ends up with configure: error: assembler too old, .cfi_personality support missing. I know it is that my system is too old. But I want to know if there is anyone have good ways to solve it.
P.S. The app of sublime test requires GLIBC 2.11.

I know it is that my system is too old.
Please note that unless done very carefully, updating glibc may easily render your system un-bootable.
The solution to configure problem is easy: update binutils first. This will give you assembler that supports .cfi directives.
Once that's done, you should be able to configure and build glibc itself.
P.S. If you don't want to update the system binutils, you can configure binutils to use a different --prefix, and set your PATH to point to that alternate location while configuring and building glibc.

Related

glibc: Is there a way to get the used configure command line options?

I want to update the distribution version of glibc and in order to keep the distribution settings, paths, ... I need the original used configure command line options.
Running gcc -v displays under Configured with: the configure command line options.
Is there something similar for glibc?
Unlike GCC, GLIBC doesn't record its configure options anywhere, so the direct answer is no.
However, if you download the source package for your current version of glibc and build it (precise commands vary between distributions), then you'll know how your current version has been configured.
P.S. Upgrading GLIBC incorrectly is one of the easiest ways to render your system unbootable. Make sure you have a suitable system recovery disk, and know how to use it before attempting this upgrade.

Compiling Vim on OS X 10.10.3 does not work

[I am not sure whether this fits here or should be moved to apple.SE]
Today I got the idea to recompile my vim in order to get the latest updates. I have once or twice before followed the suggestion in this answer so I did it again. I cloned the repo and ran
./configure --prefix=/opt/local/ --with-features=huge
(I tried with no options, problem persists)
Invariably, compilation aborts when the compiler attempts to parse ObjC-Files (for whatever reason it has to)
/usr/include/objc/NSObject.h:22:4: error: unknown type name 'instancetype'
- (instancetype)self;
It seems the compiler does not know the current Objective-C standard.
There seems to be a problem with gcc because I found this bug ticket. However, the most recent update on this is from last year.
Can someone suggest a way to make this work?
EDIT: I know I could install it via homebrew or macports; yet I am still very curious how to fix this particular problem.
Also I tried manually changing the compiler to clang like so
CC=clang ./configure --prefix=/opt/local/ --with-features=huge
After simply setting CC=clang before running (which is what the configure help seems to advertise) and seeing it did nothing. However when specifying a compiler this way (I tried the same with gcc as well), many configure checks turn out no and it eventually aborts.
I am assuming that gcc has not been configured with Objective-C support (it supports at least C, C++ and Objective-C and the installer can opt for whatever support they want).
It's possible that the 3rd-party clang is in the same boat. However I know that the Xcode version supports all 3 languages and will pick-up the correct OSX Cocoa runtime libraries, so using that appears to have solved the issue:
$ CC="xcrun clang" ./configure --prefix=/opt/local/ --with-features=huge
However just using clang should have worked as well, if which clang returns /usr/bin/clang as you say it does, so I'm at a loss to explain exactly why that didn't work.

What is config.log on osx and where does it live?

Can anyone explain what 'configure' is and does, where the config.log file can be found in general?
This is in relation to a specific problem ( gcc not working - Xcode 3.2.6 - Snow Leopard ) but I thought this question might be of more general interest:
When trying to install rubies with RVM, and I think possibly anything involving Xcode's gcc compiler, or possibly even more general than that, if there are errors then the logs usually refer to a config.log file. E.g. in my /yaml/configure.log I get:
configure: error: in `/Users/duncanstuart/.rvm/src/yaml-0.1.4':
configure: error: C compiler cannot create executables
See `config.log' for more details
Googling around suggests that this file is specific to the package being installed, but various posts give a number of different locations, none of which exist on my machine - e.g. Error installing PostgreSQL on Mac OS X 10.5 using MacPorts says it's somewhere under /opt/local/var/
Can't install Ruby under Lion with RVM – GCC issues contains an example config.log which says:
This file contains any messages produced by compilers while running
configure, to aid debugging if configure makes a mistake.
configure is part of a common source package layout - it's usually responsible for inspecting the target system and seeing what compilers, syscalls, libraries etc. are available on it. Using this information features are then enabled/disabled at build time.
Often (thought not always) it is automatically generated by autoconf from configure.ac (or configure.in).
config.log is used to store the results of tests - this can be useful to developers or to try and figure out why some optional feature was not built. It's stored in the current directory, at the time configure was called, thus for "in tree" builds it would be found at /Users/duncanstuart/.rvm/src/yaml-0.1.4 (or possibly a directory or two up if there was a sub directory being configured).

Getting MPFR to build on cygwin

I spent the whole day setting up GCC as per
http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0
On the gcc make step, it told me it needed a c++ compiler to continue for whatever reason,
So I updated Cygwin in the usual fashion and got gcc-c++.
After that, cgywin did me the courtesy of deleting the 3 prereq libraries that I had installed previously,
So I went about remaking them. GMP worked fine, and then I got to MPFR. For whatever reason MPFR is throwing this error:
configure: error: libgmp not found or uses a different ABI.
The resources mention this error here.
I’m pretty sure its finding GMP alright as cygcheck shows it up no problem, and the config even mentions it finds it.
When I try:
./configure --with-gmp-build=/gmp/,
it throws:
error: header files gmp-impl.h and longlong.h not found
So far I have not been able to get MPFR working, despite googling and trying for hours.
MPC also fails to find GMP in the usual manner.
I've also tried just handing the libraries to GCC in a subdirectory and letting it compile them.
When I try that, it gets to the make step, then throws a stage1-bubble error and fails. No description of the error or anything.
I have no idea what else to try.
After compiling and installing gmp, I had the same problem building mpfr until I set correctly the library search path:
export LD_LIBRARY_PATH=/usr/local/lib
export LIBRARY_PATH=/usr/local/lib
export CPATH=/usr/local/include
as it is explained in the http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0
Instead of this:
./configure --with-gmp-build=/gmp/
USE THIS:
./configure --with-gmp-build=/gmp
It doesn't like having the "/" at the end.
I know this post is a bit dated, but I was looking for an answer or results to a similar situation but with much more current versions of the same libraries. While reading this post as for some suggestions as well as other online material I was able to piece everything together. So for anyone who may be working with the newest releases here it goes:
First you will probably want to configure, make and install GMP first for both C and C++ as static libs; also make note of the architecture x86 or x64. Once you run make, make check, make install; and you are confidant that you have no errors, then when you go to configure MPFR you will want to run it as such:
./configure --with-gmp-build=/path/to/gmp --enable-static --disable-shared
and if the paths are set properly this should give you the needed generated make file.
I'm brand new to Unix-Posix environments and commands and new to Cygwin. I've mostly used Windows platforms and very few Macs or Apples. Matter of fact I've only been working at this for a little less than a week as I'm trying to do the same thing. So now I'm venturing into a whole new world of Unix... but it's sort of simulated through Cygwin as I'm still running windows.
I'm trying to build GMP, MPIR, MPFR & MPFRC++ all from the latest original distributions and eventually will try to integrate them into Visual Studio 2017.
I had actually found this post because I was able to build MPIR through visual studio with the help of python and vyasm, but as for GMP I needed Cygwin with GCC. It took me a little while to figure out how to get GMP to build properly but once I did and ran the tests I was able to have all pass with 0 failures. I then started to work with MPFR the same as you.
My similar issue was after I ran ./configure as default, it was giving me the message that the libgmp wasn't found. Also if I tried to call make, it would do nothing as the make file didn't exist. This led me back to doing google searches... While searching for tips, suggestions etc. I came across this Q/A. While I was reading this Q/A, the install files, some other FAQ and even another website, I was kind of able to piece everything together and what I have found that works is what I suggested above.
Not only do you need to set the flag --with-gmp-build but you also need to set the appropriate library types that gmp was built as and you need to make sure that the architecture types match too. They need to have the same matching ABIs.
Ah, just as I was about to finish up typing this answer, make check just finished running through Cygwin and I have a result of:
Testsuite summary for MPFR 4.0.1
============================================================================
# TOTAL: 180
# PASS: 180
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
I hope this helps you out. The only thing is for myself; I'll have to go back and probably run all of this again from the beginning including GMP only because I believe I only did GCC and not G++ and my next step is to try and build MPFRC++.
Then I might try to do some related libraries from here afterwards. My first phase is to try to build them all through Cygwin and GCC/G++. The next step will be to try and port them over to Visual Studio 2017.
You might want to use --with-gmp-lib=/path/to/gmp/lib/dir

glibc Linux based

I am currently using ubuntu 9.10 with the glibc version 2.11.1-0,
well i am doing a project, that i want to test with the another version of glibc that is 2.5-58, i wanted to know following things regarding this:
How to compile the version of 2.5-58, however keeping the previous version?
How to link the existing programs with the binaries of newer version of glibc?
I would be highly obliged if anybody can help me!!!
Thanks
If you want to manually compile another version of glibc, then I suggest you configuring (./configure script run) it with --prefix option to install not to /lib, /usr/lib but to /home/mehul/glibc2.5.58test/lib and /home/mehul/glibc2.5.58test/usr/lib
But compiling of glibc is not very easy thing, so another way is to get glibc 2.5-58 in compiled form from other linux and manually copy it to some subdirectory. Then you can override library search path of gcc and recompile your lib with libc from subdirectory.
Or you can use LD_LIBRARY_PATH to override library search path of compiled binary to use older glibc like this:
$ LD_LIBRARY_PATH=/home/mehul/glibc2.5.58test/lib /path/to/your/application
If you know that that version of libc is used in an older ditribution, you could install that distribution in a chroot/scratchbox/kvm/qemu/livecd or other such system for testing and building. Or there may be some other build farm type solution. Then you'll have an authentic system to test on that will not mess up your up to date one. It'll also be repeatable if you keep that system image.
If this isn't about a specific older release, why on earth would you want to test against a specific very old libc?

Resources