I have freetype2 installed on my system but I am also trying to install it from source, as well.
My installed version is here: /usr/lib64/pkgconfig/freetype2.pc. That file is listed as version 20.0.14.
To compile another tool, namely fontconfig, I need freetype2 >= 21.0.15.
So I downloaded freetype2 from its source git repo.
The trouble I'm having is that repository doesn't list any version even close to 21.0.15+. All of the tags in that repository are listed as VER-2-6-2, VER-2-9, VER-2-9-1, etc. And the generated freetype.pc file which is created after compilation are also listed as 2.6.2, 2.9, 2.9.1, etc. The version number is not 21.0.15 or even 20.0.14, which my CentOS 7.6 already has.
What determines the listed version in the freetype.pc file? Where can I find the version of freetype that will create a .pc file of >= 21.0.15+? Any clarification would be greatly appreciated.
Apparently the reason is because I was building freetype using CMake. And in the CMakeLists.txt, it's defining a version based on the version of freetype.
# . `CMakeLists.txt' is provided as-is since it is normally not used by the
# developer team.
So it's unsupported. That's why the version number doesn't match.
In reality, the version number actually comes from libtool. See this table. e.g. I was building 2.10.0 freetype, so the freetype.pc should have been written with a version of 23.0.17
And if you build using configure, instead of cmake, you can find that exact same version 23.0.17 listed as "23:0:17" in the builds/unix/configure.raw file.
Related
I have two versions of Octave installed, version 3.6.4 installed via the package manager (Linux Mint Debian), and version 4.0.0 compiled from source. I also have numerous .oct files in a folder pointed to in an .octaverc file. My problem is that the version 4.0.0 cannot "see" these .oct files and if I try to call them the whole session crashes unless I recompile them under 4.0.0 with mkoctfile. However, doing this means that the version 3.6.4 cannot "see" them and trying to call them gives an error message
failed to load: liboctinterp.so.3: cannot open shared object file: No such file or directory
How can I get both versions to recognize my .oct functions without having to recompile them each time?
I copy the answer from Mike and Olaf from the help mailinglist (crossposting http://octave.1599824.n4.nabble.com/Oct-files-run-in-Octave-version-3-6-4-or-4-0-0-but-not-both-td4672690.html)
Short answer: you can't.
The Octave library API and ABI change between releases. Octave 3.6 was liboct{ave,interp}.so.1, Octave 3.8 was liboct{ave,interp}.so.2, and 4.0 is liboct{ave,interp}.so.3. These libraries are not forwards or backwards compatible.
You can compile your oct-files in two (or three?) different paths with the
wanted Octave version in the path.
If you want to install your files system-wide, a good candidate directory for the differently compiled oct-files seems to be
fullfile (OCTAVE_HOME (), "lib/octave/site/oct/", octave_config_info ("canonical_host_type"))
assuming OCTAVE_HOME () is different for each of your Octave versions. This directory seems to be in the path by default.
If not system-wide, you could check OCTAVE_VERSION () in your .octaverc and set the path differently for each version.
I am running stack Version 2.1.3, x86_64 hpack-0.31.2 on cygwin. A Haskell project that I am trying to build requires the use of regex-pcre-0.94.4 which in turn requires the pcre library. The exact message I get is:
$ stack build
regex-pcre> configure
regex-pcre> Configuring regex-pcre-0.94.4...
regex-pcre> Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe: Missing dependency
on a foreign library:
regex-pcre> * Missing C library: pcre
regex-pcre> 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.
There does not seem to be an easy way of obtaining a relatively recent version of pcre binaries for Windows (the ones at http://gnuwin32.sourceforge.net/packages/pcre.htm are too old for my purposes). There is a video showing how to build the binaries from source but before I go that route, there are some relatively recent precompiled binaries available at https://github.com/dragokas/PCRE but I have no idea what to do with them or where to place them. This is beginning to look like a lot of work that I am wondering if its worth it or I should just drop the idea of doing it in Windows and move to Linux. Any ideas or suggestions?
PS. I also notice that cygwin already has a pcre library (/bin/cygpcre2-16-0.dll). but as this looks like a 16-bit library I assume it won't work, and again I am not sure how to tell stack to use this.
Here I found the answer:
regex-pcre doesn't support Windows, at least the current
regex-pcre.cabal doesn't work well on Windows.
Try regex-pcre-builtin, it's the same as regex-pcre, but with
PCRE sources bundled in. I don't know why the author doesn't merge it
into regex-pcre, but creating a new package for this.
I had to change only name regex-pcre to regex-pcre-builtin (as versioning is the same) in my .cabal file that installs dependencies with stack build. (example: ./your-project-name.cabal)
I've just spent about an hour going in circles trying to get version 2 of Cabal. Initially I found that the version that came with my LinuxMint install was version 1, so I tried cabal update, didn't do it. So I found instructions which said to use cabal install Cabal cabal-install. Did it, got an error. Found that the error apparently had to do with using the most current version of Haskell. So I installed version 7 to get Cabal. Seemed to work, looked like I finally got Cabal version 2. But I also want the most current version of Haskell so I downloaded the binaries for it and installed that again--now it seems like Cabal is set back to version 1. Is it not possible to have both version 8 of Haskell and version 2 of Cabal?
Along the lines of danidiaz's comments, I suggest directly installing cabal-install in your home directory.
Begin by making sure you are actually using the 8.x version of GHC you want (use which ghc and ghc --version if need be). Also, get rid of any other cabal-install versions you might have installed, so that there is less margin for confusion.
The [directory] ~/.cabal/bin is not in my PATH variable, should I put it in toward the front of its definition?
Exactly. ~/.cabal/bin is the default location for executables locally installed with cabal-install, which includes cabal-install itself, and so it must be in the PATH. Putting it towards the front of the PATH will give it priority over any system-wide installation of cabal-install installed with your package managers. (Note that that won't be an issue if you remove said system-wide installation beforehand.)
Once the terrain is clear, you can download a suitable binary tarball from Cabal's download page, extract the executable and put it in ~/.cabal/bin. As danidiaz notes, the binaries there aren't necessarily at the latest stable version (as I write this, the Linux binaries are 2.2.0.0 rather than 2.4.0.0), but that likely won't matter, as once you have some version of cabal-install available you can simply run...
cabal new-update # For version 2.4 or above; if not, use cabal update instead.
cabal new-install cabal-install
... which will update your cabal-install to the latest stable version.
(Note that I'm using the new-* cabal-install commands. I strongly advise you to do the same.)
Also, looking through the Cabal folder, I don't see binaries. The only folders present are Distribution, Language, tests, and doc.
It sounds like you downloaded the sources of Cabal, the library, rather than the ones of cabal-install, the tool. The cabal-install sources are also available from the download page linked above (as I write this, their version is 2.4.0.0). If you are getting them from GitHub instead, you should look into the cabal-install directory, rather than the Cabal one. Either way, once yo are in the appropriate directory, to install from source run...
./bootstrap.sh --sandbox
... which only requires GHC (as opposed to a pre-existing cabal-install). Once it finishes building cabal-install, the script will tell you the location of the executable (presumably in a .cabal-sandbox/bin subdirectory). Copy the executable to ~/.cabal/bin and proceed as before.
I am trying to build a program as most others available on linux:
configure, make, make install.
However when I try to configure it I get the following message:
checking for gtk-config... no
checking for GTK - version >= 1.2.0... no
*** The gtk-config script installed by GTK could not be found
*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GTK_CONFIG environment variable to the
*** full path to gtk-config.
configure: error: Cannot find GTK: Is gtk-config in path?
I have got gtk 2.x on the host machine. And when I run which and locate on gtk-config I get nothing back. Since I have the source what patches can I apply to fix this?
You need to install the development files for GTK 1.2; the name of the package depends on your distribution.
I'd like to warn you, though, that GTK 1.2 was last released 15 years ago, in 2001, and hasn't been updated since — which also implies that the application you're trying to build is also hopelessly outdated.
GTK+ 2.0.0 was also released in 2001 and it's currently in deep maintenance mode (the latest version is 2.24.29 and was released in 2015); GTK+ 3.0.0 was released in 2011, and it's the currently developed version of the API.
You cannot really apply patches to compile an application written with the GTK 1.x API using any newer major versions of GTK+ (e.g. 2.x or 3.x); each time the major version of GTK is bumped, the API is changed in a non-compatible way. You would need to port the application to the new API.
Additionally, if an application depends on GTK 1.x it's also likely that it will depend on older versions of existing libraries; or deprecated ones. You will need to find all the dependencies and ensure that they can be installed in parallel with the ones you have installed in your system.
You could try using the compatibility wrappers developed by OpenSUSE team that try to emulate GTK1.2 by some wrappers and/or automatically patching source code to be compiled, to be able to use GTK2.0 instead.
Have a look at https://github.com/openSUSE/gtk1-compat - perhaps it may work for you. I didn't test it, however, myself.
I was trying to build OpenSSL-1.0.1e for RHEL5 platform.
I got few file not found errors from rpmbuild, after further analysis i found that package builder was searching for libssl.so.10 and libcrypto.so.10. But, the actual files created were libssl.so.6 and libcrypto.so.6.
So, i have replaced the soversion macro with 6 instead of 10.
The package building was successful.
Is there any issues replacing the library version number for latest openssl with 6 instead of 10 in RHEL5 platform ?
If any interfaces have been removed going from .6 to .10, it is very possible that it breaks applications requiring a symbol that existed in the actual .6 but not in your .10 renamed to .6. Read [1] for more information about sonames.
In any case, this is definitely bad practice and should be avoided. If you have an application which requires a newer version of OpenSSL than what comes with RHEL5, I'd rather just bundle the newer libraries with your application and use LD_LIBRARY_PATH to have the directory containing the bundled libraries be searched before the system directores.
[1] http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html