On my OS X box, brew install unison gives me version 2.51.2. But the system I need to sync with runs CentOS 6.10 for which there appears to be no existing 2.51.2 binary. I also can't compile from source on that machine as it doesn't have the right tools and I am not root.
To solve this I would like to compile unison from source on my Ubuntu machine on which I am root. But this has to be a static compilation to run on the CentOS machine.
How can I make a static binary of unison?
The Makefile has the line include src/Makefile.OCaml but I don't know anything about OCaml and am not sure what I would need to change to make a static binary.
In the Makefile, there should be a line STATIC = false. Either change that to true, or just compile with the line make STATIC=true.
Some caution, according to this blog post the STATIC option doesn't actully do anything as of at least version 2.32.52, and I see no changes in the change log to indicate that this has been fixed, but the author of the blog post says, and I've confirmed, that building a static binary works for the latest version of Unison, 2.48.
Related
I have Unison 2.40.63 on both Windows and RHEL, all configs are working fine except when I try to run it first time it gives
Fatal error: Internal error: New archives are not identical.
Retaining original archives. Please run Unison again to bring them up to date.
First, just to cover our bases, I would check to make sure the same version of Unison is getting called on each machine. Unison 2.40.63 may be installed on both machines, but maybe there is a different version hiding in the PATH being called first. See unison -version.
That's probably not the issue though. This was a bug that cropped up before using older versions of Unison. See here and here. If I understand right it's because the versions of Unison were compiled with different versions of OCaml. Anyways:
There are much newer versions of Unison available. Unless you have a good reason to, I would upgrade. I'll bet this will solve your problem.
If you really really want version 2.40.63, then on each machine you'll have to first compile and install OCaml 3.12.1 from source, and then compile Unison 2.40.63 from source with OCaml and install it. This is what I had to do awhile ago to get things working with this version of Unison.
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.
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.
I am currently trying to build a gcc 4.4 on a newly updated ubuntu 11.10. However building the compiler always fails with some problems, when trying to bootstrap.
First crti.o and crtn.o could not be found. I symlinked them into another directory within the search path, and so I could get a bootstrap compiler. However now it fails with the message:
configure: error: C compiler cannot create executables
I tried out to use the intermediate compiler on a simple test program, and I get the message:
$ ./host-x86_64-unknown-linux-gnu/prev-gcc/xgcc test.c
xgcc: error trying to exec 'cc1': execvp: File or directory not found
So something is seriously messed up with the paths of my intermediate compiler it seems. When I did the same thing on ubuntu 11.04 everything just worked fine.
I used the following command line to configure:
./configure --prefix=/opt --program-suffix=44
I also tried both a VPATH-built, as well as an in source build, but both have the same problem. I still have the gcc44 from before the update lying around within /opt, but it has become unusable since the update.
Is there any easy way to get gcc 4.4 working under Ubuntu 11.10? I does not have to be a self build compiler, if I can just download a package and install that, it would be fine as well.
This is caused by Ubuntu's switch to multi-arch. Basically all the "standard" paths have been changed so you can install libraries for multiple architectures on the same machine without any clashes.
Ubuntu GCC has been patched to fix the problem, of course, but the upstream compiler still wasn't fixed last time I checked.
See here: https://askubuntu.com/questions/69365/cant-build-gcc-anymore-since-upgrade-to-11-10
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?