Dear expert community,
I so often face problems that software will not compile or work because libraries (specifically .so files) are too new.
If I try to install the old library (apt-get on Ubuntu) I can get errors that it is "not installable" because of conflicts...
So following problems arise in my mind:
1) how to install old libraries/packages together with newer ones for example on Arch Linux or Ubuntu Linux ?
2) how to avoid conflicts: the older library should be used (linked) only with the "problematic old" software and/or if I specify this explicitly ?
3) how can I check with cmake, make or the autotools if a specific (old) library version is installed and in case not automatically get it and install it and use it without conflict with a newer version ?
Thank to any expert for a help
Linux package managers normally don't allow installing multiple versions of the same package. You have to install older versions yourself, by hand, from source, preferably to some private place like /usr/old-versions.
You link problematic software like this:
<link command> -L /usr/old-versions/lib -Wl,-rpath=/usr/old-versions/lib
and it automatically uses the old version of the library.
There is no way to do that automatically.
Note that you may need to compile against older versions of library headers too, not just link against old versions of the libraries.
Related
Julia has a package for binary decision diagrams called CUDD_jll available from JuliaHub. The package is able to install and compile on the Apple M1 architecture. It does appear to install and compile on macOS v13 running Julia v1.82. But the user interface from an older package CUDD does not appear to be compatible with CUDD_jll.
What is needed is a test or examples revealing user commands for initializing cudd, defining logical variables, and the basic operations of AND, OR, NOT.
Does anyone have such information they will share?
_jll packages are generally not meant to be used directly, they're backend dependencies that will be automatically installed when you add a package that uses them.
In this case, CUDD.jl is the package you want to install and work with. That will automatically install CUDD_jll as a dependency and use it. Actually, the current CUDD.jl doesn't yet use CUDD_jll as a backend. It instead does its own download of the CUDD library, from a source that doesn't provide M1-compatible binaries. CUDD_jll is a recent effort to change that. It does provide binaries for the M1 architecture, but is yet to be merged in as a backend.
In the meantime, you can try ] add CUDD#update-to-yggdrasil to directly add the branch that uses CUDA_jll as the backend, and see if that works for you. (Once the PR gets merged, you can remove this branch-specific dependency and ] add CUDD like before.)
The Apple M1 system is not compatible with CUDD. My mistake, sorry.
I know there is usually no point to have older IDE versions, but in my team we had issues with our environment and cmake architecture when we tried to upgrade from 3.6 to 4.0 so we stepped back.
Now I want to test the new version of QtCreator to see if it's working fine, but without removing my current version because I could need it to work on urgent tasks.
The Qt install folder allows to have different Qt versions but there is only one Tools folder for QtCreator. Is there any simple way to add another version ? Or if I just install it somewhere else by myself, can it mess up my configuration and Qt installation ?
(I'm on windows btw)
Thx !
Just grab the Qt Creator stand-alone package and install that somewhere.
Do make sure to keep you user settings though, as Creator will upgrade those and your older version will not be able to read all of them afterwards. You can either:
Make a copy of (%APPDATA%/.../QtProject or ~/.config/QtProject IIRC) of your existing settings
Specify a different setting folder for QT Creator by starting the new Creator with the option: -settingspath /some/dir.
I already searched on the net a way to update the SQLITE3 version of Xcode, but I didn't found any working way. It is a way to do it?
If you want to use your own version of sqlite3, perhaps because you want to use newer features only provided by a later version, then probably the best thing to do would be to create an Xcode static library project to build sqlite3 and then include that library with your app (statically linked). This will avoid using the system version.
This should be fairly trivial, given the number of source files that make-up sqlite3.
You could probably make a dynamic library version, but that's slightly more complicated, though certainly possible.
Is there a correct way to install a new version of Mono (for example 2.10.5) having an older version already installed (for example 2.10.4)?
Which way is it possible to follow?
Uninstall the older version and then install the new one
Overwrite the older version with the new one
Thank you in advance.
Just install and don't worry about it. Frameworks support multiple versions. You'll wind up with both versions available.
If you definitely want to get rid of the old version(s), then just remove the entire Mono.framework folder from /Library/Frameworks before installing the new version.
If it is installed the same way as on Linux (configure, make, make install), you can surely overwrite it - just use the same prefix :)
I'm wrote an application and I need to execute it on Gentoo,
but when I try run it, I get the following message:
/lib/libc.so.6: version `GLIBC_2.3.4' not found (required by /usr/local/myapp/lib/myapplib.so.1)
the current GLIBC version in this gentoo is 2.3.2.
I can't update this glibc, because I don't have permission, so I need to 'downgrade'
my glibc to the same version (2.3.2) ... how can I do it?
tks,
The "/lib/libc.so.6: version `GLIBC_2.3.4' not found" problem comes from trying to run a binary compiled against a newer glibc on a system with an old version of glibc. Downgrading glibc is strongly discouraged for this reason.
Since you say you wrote the application, it seems to me that the simplest solution is to recompile the application on the system where you plan to run it.
I'm actually wrestling with the same issue, so maybe I have some information that can help.
In short, your binary was compiled to look for libc.so.6. GLIBC_2.3.4 is in libc.so.5. As far as I know, if you downgrade your glibc on your dev machine some of your other programs may not work properly (because they were compiled to look for the current version). Somehow CentOS/RHEL have a compat-glibc package that can live along side of a current glibc without causing this error. If your dev box uses CentOS/RHEL, install that package/recompile and you should be good to go. You may need to use an older compiler for it to look for the older library. If you're not developing on CentOS/RHEL, continue on.
My plan of attack today is to compile glibc from source. This means using a compiler that was released around the same time as the older version of glibc. You may run into some stumbling blocks (such as needing an older version of buildutils, etc.), but my hope is once the libc.so.5 is compiled and installed into /usr/local/lib my application will find that before it finds libc.so.6 in /lib.
So there it is. It's not for the faint of heart, and it's definitely not a quick solution. Today I plan on testing this out, so I can't really say it's the right solution. Please, hivemind.. if I'm flat-out wrong correct me and save this poor soul from this winding torturous road :-)
EDIT: link to glibc sources