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.
Related
I am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
I followed this install wget tutorial,
After I ran this
./configure --with-ssl=openssl
It ran so many checks, what exactly it did? Did it change anything in my system?
If it does, then, is it safer or more fault prove to use the package management tool like MacPort or such so that such 'configure' will not be done manually like this or does those tool do the same thing in order to make wget work?
Sorry, I am pretty noob on shell commands.
Thanks
It's part of the build process. The configure script collects information about your system and build options into a local file, nothing more.
Typically, this script is created by autoconf and is used to figure out whether the prerequisites for a build are properly installed, etc. It will collect this into a file config.save and also possibly generate a makefile and/or other build infrastructure in order for make to be able to concentrate on compiling and linking the source files.
Neither configure nor make should be expected to change anything outside of the directory tree where you run them.
Conventionally, make install will copy the final build artefacts into place so that other parts of your system can find them and use them.
See also http://www.edwardrosten.com/code/autoconf/
A prepackaged binary will already have been built on a remote system before it was packaged (though there are package managers which allow or require you to build locally; Gentoo Linux famously uses the latter approach) and is often the simplest way to get a tool if you don't have special requirements, such as building with a specific SSL version, or disabling SSL entirely, or getting a bleeding edge version before anybody has packaged it.
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.
I made a second development on levigo, when I finished it and try to install it on my system with the following command:
go install github.com/AndreMouche/levigo/
it reports the following error:
# github.com/AndreMouche/levigo
/home/fun/software/go/go/pkg/tool/linux_amd64/6c: unknown flag -FVw
Does anybody know how to fix it?
Your go command probably differs from your go tool chain.
Check if the right version of the go tool is in the PATH of your shell or try reinstalling go.
The go tool calls tools like the compiler (e.g. 6g) and the linker. If the go tool version
does not correspond with the version of these tools, said tools may get called with parameters
they don't yet know or they don't know anymore.
Check the version using these commands:
$ go version
$ go tool 6g -V
They both should report the same version string.
See this and this post for related problems.
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?