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.
Related
In order to use iup in Chicken Scheme, I need to provide some dependencies. One of them is IM (imtoolkit), which I found on https://webserver2.tecgraf.puc-rio.br/cd/en/building.html , where it links me to sourceforge. From there I can download the source code to compile myself, but there are no instructions I could find how to do that and there is not the typical configure make make install structure, because there is no runnable configure. So I decided to use the precompiled version.
When I run sudo chicken-install iup I get the error:
iup.c:17:16: fatal error: im.h: No such file or directory
compilation terminated.
So I know I need IM somewhere. It is not in the repositories. In another question, I learned about specifying a path to a library when using chicken-install. This makes the command I try using CSC_OPTIONS=-I/home/xiaolong/development/ChickenScheme/IM/precompiled/include chicken-install -p ~/.chicken-scheme/eggs/ iup. However, still it results in the same error.
How can I use the precompiled library?
Note: Compiling it myself is still not totally out of the picture, if I could find any instructions on how to do it.
Info
OS: Xubuntu 16.04 64bit
Chicken Scheme version installed from the repositories:
CHICKEN
(c) 2008-2014, The Chicken Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.9.0.1 (stability/4.9.0) (rev 8b3189b)
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
bootstrapped 2014-06-07
Perhaps you can try this Makefile by Matthew Welland, for the Megatest UI. It's the only way I've ever got iup to work at all (on an Ubuntu box). Unfortunately, the Makefile is quite complex and it does a lot more than just install iup.
From what I can gather, it indeed downloads all the pre-built binaries of iup, im (imtoolkit) and cd (canvas draw), and it extracts them all into the same directory. Finally, it manually copies include files and shared objects around into the CHICKEN prefix. That's not exactly a best practice, but if it helps to get things up and running, maybe you can give it a shot. My advice would be to do it in a VM first, to avoid making too much of a mess on your main system.
I've been trying to install hmatrix on my (64-bit) Windows 10 computer; after searching through and trying many possible solutions (including the instructions under "Windows" and "Alternative Windows Build" given here), I decided to pursue the course of action given on this Reddit thread.
However, when I type in the command
cabal install hmatrix -fopenblas --extra-lib-dir=${c:\msys64\mingw64\bin} --extra-include-dir=${c:\msys64\mingw64\include}
into the MSYS2 shell, the following log is given:
Resolving dependencies...
Configuring hmatrix-0.17.0.2...
Failed to install hmatrix-0.17.0.2
Build log ( C:\Users\Christian\AppData\Roaming\cabal\logs\hmatrix-0.17.0.2.log ):
Configuring hmatrix-0.17.0.2...
cabal.exe: Missing dependency on a foreign library:
* Missing C library: libopenblas
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Leaving directory 'C:\msys64\tmp\cabal-tmp-4244\hmatrix-0.17.0.2'
cabal.exe: Error: some packages failed to install:
hmatrix-0.17.0.2 failed during the configure step. The exception was:
ExitFailure 1
However, when I check the directory c:\msys64\mingw64\bin, I see that libopenblas.dll is right there; I don't know why cabal can't seem to find it.
Any insight into why this is not working or what to do?
UPDATE:
The files libopenblas.dll.a and libopenblas.a are in the directory c:\msys64\mingw64\lib. Is it possible I need to somehow include this directory as well? (If I do, how would I do that?)
I also downloaded the files in Alex Vorobiev's comment below and put them in c:\msys64\mingw64\bin if they are .dlls or c:\msys64\mingw64\lib if they are .libs. The header files were already contained in c:\msys64\include\openblas.
I tried several variations on the command in the original post after making these changes, including switching \bin with \lib and switching \include with \include\openblas, but all of them still give the same error.
I'm a bit suspicious about the
if os(windows)
if flag(openblas)
extra-libraries: libopenblas
in the cabal file, could you unpack it and remove the "lib" part? If that doesn't work please post a log with -v3 output. I've seen quite a few people with troubles installing this package. So could you also open a ticket on the GHC bug tracker if this doesn't work (and CC me "Phyx-")?
Secondly, you never said which version of GHC you're using. 8.0.1 should have far less trouble (and won't need the hack to get it working in GHCi) since the runtime linker has been overhauled and should be much better on Windows. 8.0.2 will likely include the new import libraries support as well.
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 don't know whether this is actually an SDL issue or just me not knowing how to build packages from msys/mingw. What I have done thus far:
downloaded latest mingw-get-inst.exe from sourceforge and ran it. This installed a C:\MinGW\ directory with msys inside. This brought me to my first bit of confusion. When I opened the mingw shell, rather than bringing me to my /home/ directory as I expected ( I have used mingw before and remember this being weird ) it placed me in /c/Users/me/.
I figured that this must be my home directory and put the extracted SDL-1.2.15/ in this location.
I then ran:
cd SDL-1.2.15
./configure --help
but received sh: ./configure: No such file or directory.
I then created a /c/MinGW/msys/1.0/home/ directory, set that as the HOME environment variable, moved the SDL folder into it and tried to configure again with the same result.
There are a few things I really dont understand about installing packages that I hope someone can clear up. I have installed a few before and the ./configure; make; make install; seems to be a common procedure. I know msys provides the functionality for make, but is configure a file that is supposed to be included in each package? If so, why is it not in the SDL package/how do configure it?
I have been following instructions from here and they seem to have worked for others in the comments. The bottom-most comment tells that mingw-get-inst works, though I did try it both ways.
I have a feeling my lack of msys/mingw knowledge is my problem.
I am on windows 7.
I had the same problem as you describe and I got SDL, SDL_image and SDL_ttf working after some research.
It seems that the configure file exists only in the source code packages. I found that out after I downloaded the SDL_image source. So, the problem probably lies in that the configure file comes only in the source packages.
However, I'm having other problems so I'm not sure this has fixed it for me, but it seems like it should.
I need to know if it is possible to compile the best and newest package in an old, ancient system. Why? Well I'm limited at my company: I need to develop an application in an old Debian 3.0 server and I would prefer to use newer software to accomplish my task. Unfortunately, I'm not allowed to upgrade nor install any package.
Specifically, I want to parse XML files comfortably using xmlstarlet to do so. This server doesn't have it installed; if I download an older version of xmlstarlet supported by the system it's too old that I just lost the functionality I need. It just has three dependencies: libc6, libxml2 and libxslt1.1 (which are installed but are too ancient for a newer version of xmlstarlet)
So the question is: is there a way I can download this package and its dependencies (I think they are few and simple) and somehow compile them to work locally (not necessarily on the system's path, just in a working directory) without affecting in any way the legacy packages of the same name?
This system doesn't has PEAR either, nor PHP5, nor xmllint and I want to avoid coding in PHP4 to parse these XMLs. I really would like to work with xmlstarlet.
The answer to How to specify non-default shared-library path in GCC Linux? Getting "error while loading shared libraries" when running looks like it should work fine.
Or you could try static linking:
./configure --enable-static-libs