Background
We have dependencies to several Xalan and Xerces versions in our rather large C++ system. This has accumulated over the years, and is not optimal for several reasons.
Now we're migrating from Solaris to Linux, and we think it makes sense to consolidate third party dependencies to a minimum.
We've determined that we still need Xerces 2.8 and Xerces 3.x. And Xalan 1.x
Target platform is RHEL6.
Problem
From RHEL repo we can get Xerces 3.0 and Xalan 1.10 (build against Xerces 3.0)
We've installed Xerces 2.8, under /usr/local...
We can't figure out how Xalan is supposed to work with Xerces (link wise). That is:
Do we need two Xalan libraries, one linked against 3.x and one against 2.8?
Can we have one Xalan version, let's say 1.11, that (by some magic) works with both the xerces versions?
We can't be the only one with this problem, or are we just idiots? (which would be the best scenario... :))
From what I've just read at xerces.apache.org , Xerces 2.X and Xerces 3.x have different API's and therefore you'll need to link with one OR the other.
And as you can see from xalan.apache.org:
"The Xalan-C/C++ 1.11 library requires the Xerces-C/C++ XML Parser 3.0 or newer, version 3.1.1 is preferred.", while Xalan 1.10 requires Xerces 2.7.0 (will probably work with 2.8.0).
So yes, you will need two different versions of Xalan libraries, unless you can resolve your dependencies to Xalan 1.11.0 only, in which case you can have only one installed Xalan and one Xerces.
Probably most of all problems of xerces + xalan are because of xerces definition of XML character "XMLCh" in Xerces_autoconf_config.hpp (generated header). I have been trying to build on windows xerces 3.2.2 and xalan 1.11, and faced types missmaching...
E.g., DirectoryEnumerator.hpp, struct FindFileStruct, has function:
const XalanDOMChar* getName() const
{
return name;
}
name is "wchar_t name[260];" from corecrt_wio.h, struct _wfinddata64i32_t (it is Windows part...).
XalanDOMChar is typedef of "XMLCh".
For some reason xerces 3.1.1 generates XMLCh as "wchar_t", but xerces 3.2.2 - as "char16_t". And xalan has some code that is oriented on "wchar_t"...
Related
Apache Arrow in their documentation list that each release has two versions, a Library Version and a Format Version: https://arrow.apache.org/docs/format/Versioning.html
It appears that over the last year there have been 4 Library Versions, but it's hard to tell if the format version has changed in any of these Library Versions. Is there a way to tell what the Format Version is for a given Library Version?
Currently, I do not see a way to determine the format version programmatically. This seems like a good idea. I have opened ARROW-12594.
The latest format version is also listed on the specification page.
Since the latest version is 1.0.0 you can safely assume that all Arrow versions >= 1.0.0 and <= 6.0.0 are compiled against format version 1.0.0
I was able to install and build openCV following the instructions here (http://charliegerard.github.io/blog/Installing-OpenCV/). But after successfully creating the dynamic libraries I noticed in the lib directory there are 3 instances of each library named in the following format:
libopencv_LibName.3.1.0.dylib
libopencv_LibName.3.1.dylib
libopencv_LibName.dylib
Screenshot of the libraries
My next step is to single out only the header files and libraries I need for my project, and I'm not sure if I really need all 3 instances of every library in use. Why does make create all these extras? And which ones do I need?
Additional Info:
OS: OSX El Capitan
IDE: Xcode 7.3.1
When you build the opencv library it creates the actual *.dylib binary (libopencv_LibName.3.1.0.dylib) that contains the release, the major, and minor version. (Release = 3, Major = 1, Minor = 0). This allows you to have a dynamic style of linking to a specific version of the library. (For example, opencv often is not completely compatible between release versions. (From 2.x.x to 3.x.x), however it often is compatible between major/minor versions.(3.0.x to 3.1.x) )
By linking to the 3.1.0 version, you are locking in on requiring that specific version of the libary. (If you update opencv, it will still be using openCV 3.1.0).
However if you link to the 3.1 version, it is only caring about the Release and Major version, but will allow minor version updates. (Currently the 3.1 is a symlink to 3.1.0, but if you installed 3.1.1, it would now reference the 3.1.1 library.) I generally find it best to link to this one as it will allow you to update for bug fixes, but will not break any functionality.
Finally there is the version-less symlink, this one will always reference the latest version of opencv you have installed. Currently it references 3.1.0, but if you installed 3.1.1 it will now reference 3.1.1. This would not be bad, but if you were to install 4.0.0, it would now be referencing this binary and likely break some of the API.
I just downloaded biicode and tried to follow the getting started instructions but received an error about the Cmake 3.0 or higher being required.
However, ubuntu 14.4 uses "cmake version 2.8.12.2"
Is there a way to use biicode with 2.8 or am I stuck installing the newer version of CMake?
TIA!
No, biicode requires cmake > 3.0. There is a setup command that helps installing it:
$ bii setup:cpp
This will install CMake >3.0 in /home/user/biicode_env, and add it to the path, so it doesnt interfere/overwrite your current 2.8 installation. Biicode needs that executing "cmake" in the console actually uses 3.0, so it should be first in the path. You can manage it very easily in two different ways, with a symbolic link (/usr/bin) that you redirect as needed or adding/removing an entry in the path before executing biicode.
This is a different thing, but I woiuld like to say that I have migrated existing projects from cmake 2.8 to 3.0 without any problems, and 3.0 runs great and has useful new features. So I would recommend regular cmake users to upgrade if possible.
No, there isn't any way to change this requirement because internal biicode CMake has features, like the use of INTERFACE libraries, which are only available on CMake 3.0 or later. However, don't worry about upgrading CMake version, this one always keeps a exhaustive compatibility with older versions ;)
I've been struggling a bit trying to get this to work. Getting clojure 1.3 was a breeze, but now I've been trying to get contrib libraries to install and I get errors. Is there a guide on how to do this correctly?
The old clojure.contrib monolithic library is incompatible with clojure 1.3. See http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go
As for how to install libraries correctly, either write your own pom.xml and use maven or use leiningen (much easier!) - https://github.com/technomancy/leiningen
I'm using RHEL 5.3, shipped with gcc 4.1.2 and boost 1.33.
So, there's no boost::unorded_map, no make_shared() factory function to create boost::shared_ptr and other features available in newer releases of boost.
Is there're a newer version of boost compatible with the version of gcc?
If yes, how the upgrade is performed?
Download the latest version (1.43.0) of the Boost libraries from the Boost website and follow the steps in the getting started guide, which explains how to build Boost on a number of platforms, including Linux.
Simply download and install the newest version; it will adapt itself automatically to your compiler.
Sure, just download the latest source from link text. If you are only using header only libraries, it just needs to be unpacked. If you are using one of a handful that require a library, you will need to build those.