View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012037CMakeCMakepublic2011-04-03 16:282012-11-26 16:18
ReporterModestas Vainius 
Assigned ToBrad King 
Platformamd64OSDebian GNU/LinuxOS Versionsid
Product VersionCMake 2.8.4 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0012037: support multiarch lib paths for Debian/Ubuntu
DescriptionDebian and Ubuntu are switching to the multiarch implementation which is unique in the current Linux world. You can find more about this effort here [1]. The switch affects layout of the /lib and /usr/lib directories [2]. The latter seems to cause cmake trouble finding system libraries [3]. There is a patch [4][ additional info] proposed to fix this issue but I don't think it is acceptable outside Debian/Ubuntu in its current form.

I see at least 3 problems with the patch:

1) dpkg-architecture is not guaranteed to be available on all Debian systems (it's in the dpkg-dev package which is not installed by default);

2) older dpkg-architecture versions do not even support `dpkg-architecture -qDEB_HOST_MULTIARCH`. This is only supported in dpkg 1.16 or later (released only 2 days ago).

3) the patch implements debian-specific feature like it affected all unix systems. There is no special casing.

What's more, I'm not sure if the patch covers all cases which might break. Therefore, I would like to discuss a proper implementation with you. Please note that vanilla cmake will slowly become unusable on the future Debian (wheezy+, 7.0) and Ubuntu (natty+, 11.04) systems unless this bug is fixed. I suppose this is definitely not what you want to happen... Btw, the issue is pretty high priority for me at the moment.

So here I propose a couple of proper (in my opinion) solutions in the order of my preference:

1) Parse `gcc -print-search-dirs` output and preseed CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES with information from the "libraries: =" line. This line contains some useless cruft and needs to be filtered a bit though. For example, this could be done with `gcc -print-search-dirs | sed -n -e's/libraries: =//p' | sed -e's/:/\n/g' | xargs -n1 readlink -f | grep -v 'gcc\|/[0-9.]\+$'` in shell scripting (needs to be rewritten for cmake). The multiarch triplet itself could be extracted from the well known path in the list, e.g. /usr/lib/${triplet}.

Why do I think this solution is the best?

* CMake does not need to second guess the arch-triplet (like in the other solution below).
* This would presumably be perfect for automatic cross compiling support.
* It should also work on all GNU linux distros despite their multiarch model but you may special case it for Debian/Ubuntu at the first phase.
* It is probably the right thing to do.

2) Link library search path will be like /usr/lib/${triplet}:/usr/lib:/lib/${triplet}:/lib (not sure 100% about the order if it's important). So here you need to second guess the triplet. Typically `dpkg-architecture -qDEB_HOST_MULTIARCH` would return it, but as noted earlier dpkg-architecture might not be available. At the moment, Debian multiarch triplet is a GNU tripplet returned by `gcc -dumpmachine` with the following adjustments done (code in perl):

sub gnutriplet_to_multiarch($)
    my ($gnu) = @_;
    my ($cpu, $cdr) = split('-', $gnu, 2);

    if ($cpu =~ /^i[456]86$/) {
    return "i386-$cdr";
    } else {
    return $gnu;

Disadvantages of this solution is that these adjustments might change as new architectures are added. cmake implementation would need to be updated whenever this happens.

Feel free to ask questions. I will relay them to the person responsible for multiarch implementation in Debian/Ubuntu. Maybe he will even join us here.

[1] [^]
[2] [^] Design -> Filesystem layout section
[3] [^]
[4] [^] see attachment
Additional Information--- cmake-2.8.3.orig/Source/cmFindBase.cxx
+++ cmake-2.8.3/Source/cmFindBase.cxx
@@ -324,6 +324,14 @@ void cmFindBase::AddPrefixPaths(std::vec
       dir += "/";
+ if (subdir == "lib")
+ {
+ const char* triplet = this->Makefile->GetDefinition("CMAKE_ARCH_TRIPLET");
+ if (triplet)
+ {
+ this->AddPathInternal(dir+"lib/"+triplet, pathType);
+ }
+ }
     std::string add = dir + subdir;
     if(add != "/")
--- cmake-2.8.3.orig/Modules/Platform/UnixPaths.cmake
+++ cmake-2.8.3/Modules/Platform/UnixPaths.cmake
@@ -29,6 +29,8 @@ SET(UNIX 1)
 # List common installation prefixes. These will be used for all
 # search types.
   /lib /usr/lib /usr/lib32 /usr/lib64
TagsNo tags attached.
Attached Filespatch file icon v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch [^] (15,725 bytes) 2011-06-08 10:29 [Show Content]
patch file icon v1-0f939ee1+0002-Test-find_package-multiarch-support-12037.patch [^] (5,415 bytes) 2011-06-08 10:30 [Show Content]
diff file icon regex-update-arm-eabi-kfreebsd-hurd.diff [^] (1,881 bytes) 2011-06-12 10:40 [Show Content]

related to 0011964closedEric NOULARD Handle lib64 library on Linux 
has duplicate 0012254closed Hardcoded CMAKE_SYSTEM_LIBRARY_PATH is no good. 
related to 0012049closedPhilip Lowman Problem with cmake module FindGTK2.cmake in Ubuntu >= 11.04 (Natty Narwhal) 
related to 0012247closedBrad King python libraries are not searched under lib64/ 
related to 0012326closedBrad King [linux multiarch] /lib/<arch> is not in implicit link directories list 
related to 0012428closedKitware Robot PathScale compiler support isn't multiarch aware 
related to 0013280closed CMake does not detect multi-arch library architecture from hand-built gcc 4.7  
related to 0013742closedBrad King support multiarch include paths for Debian/Ubuntu 

Eric NOULARD (developer)
2011-04-04 02:23

Hi Modestas,

We did have related discussion concerning lib64 handling for CPack (RPM) [^]

I think that if we were to patch the Platform/*.cmake file one
should preferably do it in Platform/Linux.cmake
and not in Platform/UnixPath.cmake, unless this has to be shared
with other unices?
You'll already find a small debian specific part in Linux.cmake.

Now as you'll soon discover in the related bug, may be
the discussion concerning could be done with CPack usage in mind too.
That would help people with building appropriate package for linux,
i.e. package using the "normalized" lib path.
Eric NOULARD (developer)
2011-04-04 03:00
edited on: 2011-04-04 03:03

Some more comments.
The fact that 2) older dpkg-architecture versions do not even support `dpkg-architecture -qDEB_HOST_MULTIARCH`, is not a problem
because (correct me if I'm wrong) but as soons as some Debian-based distro is released then I bet the dpkg-architecture coming along with it should be up-to-date, right? So if dpkg-architecture bails out on DEB_HOST_MULTIARCH then we can go back to current behavior.

Now about 1) dpkg-architecture is not guaranteed to be available on all Debian systems, then I see two point of view:
    PV1) Requiring -dev packages for a CMake user is not a problem,
         because compiling is kind of "development activity".
         In this CMake may warn that a SystemSpecific required
         tool is missing and its (the one of CMake) behavior without it
         will be at best sub-optimal if not wrong.

    PV2) Debian people should make the tool mandatory in the distro
         or have some fallback (/etc/some_file) which makes it possible
         to properly get the MULTIARCH_TRIPLET.

In the end I think that if some Linux distribution has a specific behavior
it is somehow logical to use distro-specific tools to handle it. That's why
I would advice Debian developers to go for PV2 because you cannot expect
"external" tools to adapt themselves without minimal help.

Modestas Vainius (reporter)
2011-04-04 05:31

I don't think /etc/some_file is appropriate. /etc and /usr/share will be shared between binaries from different arches or one may migrate /etc/ to another host so it will get out-of-date very soon. One of the features of Debian multiarch is that linker and compiler solve all multiarch issues so they are the primary source of information.

Regarding your notes about dpkg-architecture, if that's what you want to do (requiring user to install dpkg-dev package), you can go that way. It's not a problem for me to add this dependency to the cmake package. My points were about current state of the patch which you may choose to solve or ignore.

I still like `gcc -print-search-dirs` solution the most as it's more universal. Before you adopt one solution or another, have in mind cross-compiling as well. If you adopted `gcc -print-search-dirs`, setting proper CMAKE_C_COMPILER should be enough.
Eric NOULARD (developer)
2011-04-04 06:38

Just to be clear, I'm not a decision maker here :-]
I'm just putting forward some idea.
Kitware people are the decision makers.

Now, the use of gcc seams reasonable as well
and you make a good point about covering the cross-compiling case.
Moreover I mentioned "requiring -dev package" as an option but I bet
this wouldn't be the best one.
CMake try hard not to depend on external libs, even less on

My main point is finding libraries may not be "enough" because
CMake is used to build **AND** install things so how should the MultiArch
switch be handled?

How do we help the user to
may the GNUInstallDirs.cmake module be updated for the multi-arch case?
Brad King (manager)
2011-04-06 11:55

Take a look in CMakeFiles/CMake*Compiler.cmake in any build tree. There you will see the implicit link directories detected from the toolchains. Perhaps we need to teach find_library to start looking in these.

The lib->lib64 transformation already used on non-Debian 64-bit systems is similar to this. Perhaps that code can be generalized.

Will these triplets appear under lib directories other than the standard /lib and /usr/lib (and perhaps /usr/local/lib) by any convention defined by the multiarch standard?
Modestas Vainius (reporter)
2011-04-06 15:43

For now the standard covers /lib, /usr/lib, /usr/local/lib. Bigger software like firefox will be installed into /usr/lib/triplet/firefox etc. As you can see from bug 12049, glib stuff gets installed into /usr/lib/tripplet/glib-2.0/. Likewise, find_package() Config.cmake files should go to /usr/lib/triplet/cmake. In other words, whatever is under /usr/lib currently will go to /usr/lib/current-arch-triplet to make room for other arch to be installed under /usr/lib/other-arch-triplet. /lib, /usr/lib etc. are kept for backwards/FHS compatibility and gradual switch.

/usr/bin etc. are not affected by multiarch because typically it does not matter for which arch the executables were compiled for.
Alex Neundorf (developer)
2011-05-19 16:11

The file Modules/CMakeFindEclipseCDT4.cmake already parses some output from gcc, to find the builtin include dirs and macros.
Maybe this part of cmake code can be reused somewhere for the multiarch lib stuff.
Modestas Vainius (reporter)
2011-06-07 16:28

Ok, multiarch has come to Debian unstable. Basically after 2 months of silence in this bug, it looks like I will have to go with a hack. I tried looking into developing a better solution myself but didn't get far. Anyway, it's only the start of my headaches... many Find* module hardcode /usr/lib paths...
Brad King (manager)
2011-06-07 16:52

The main problem is determining the architecture triplet reliably. We must be able to determine it given only the compiler toolchain and flags (e.g. -m64). Tools specific to the host system might not accurately reflect the target architecture, especially when cross-compiling.

Don't worry about the Find* modules that hardcode /usr/lib. Those hard-coded paths are not searched until after the rest of paths from variables like CMAKE_SYSTEM_PREFIX_PATH are searched.
Brad King (manager)
2011-06-07 16:57

As I mentioned in 0012037:0026124 CMake does detect implicit link directories from the toolchain. Will these always include the /usr/lib/triplet directory? Run CMake on some project using the toolchain for a given triplet and look at CMakeFiles/CMake*Compiler.cmake to see what directories it detects.
Modestas Vainius (reporter)
2011-06-07 17:40

Architecture is amd64.

Used to be (pre-multiarch):

$ grep LINK_DIRECTORIES CMakeFiles/CMake*Compiler.cmake
CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib")
CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib")

It is now (multiarch enabled):

$ grep LINK_DIRECTORIES CMakeFiles/CMake*Compiler.cmake
CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib;/usr/lib/x86_64-linux-gnu")
CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/gcc/x86_64-linux-gnu/4.6.1;/usr/lib;/lib;/usr/lib/x86_64-linux-gnu")

$ gcc -v -xc -E /dev/null
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-11' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs [^] --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 20110604 (prerelease) (Debian 4.6.0-11)
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1 -E -quiet -v /dev/null -mtune=generic -march=x86-64
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/dev/null"
COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64'

Multiarch paths are also in /etc/

$ cat /etc/
include /etc/*.conf

$ cat /etc/
# Multiarch support

For example, on i386 there is /etc/
But please note that both (or more) such confs can be installed at the same time (the whole point of multiarch).
Modestas Vainius (reporter)
2011-06-07 18:20

However, on the up-to-date Ubuntu oneiric CMAKE_{C,CXX}_IMPLICIT_LINK_DIRECTORIES are a bit different (no /usr/lib;/lib).

# grep LINK_DIRECTORIES CMakeFiles/CMake*Compiler.cmake
CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_DIRECTORIES "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1;/usr/lib/x86_64-linux-gnu")
CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1;/usr/lib/x86_64-linux-gnu")

I don't know why it is different, but in either case, you can rely on /usr/lib/triplet to be there.

Also please note that /lib/triplet is not in CMAKE_{C,CXX}_IMPLICIT_LINK_DIRECTORIES lists on both Debian and Ubuntu. That's probably because library development symlinks ( are never installed to /lib. But maybe this could be treated as bug [1] ...

[1] [^]
Mikael Öhman (reporter)
2011-06-08 08:56
edited on: 2011-06-08 11:44

How should *LibraryDepends.cmake files treat this?
These autogenerated files hardcode whatever paths they were compiled with. But with custom libraries, and/or, these paths might change dynamically.

As you know, this is also what has happened in Sid right now (e.g. /usr/lib/x86_64-linux-gnu/, rendering all *Config.cmake files supplied (VTK, Paraview, etc.) broken (they all hardcode /usr/lib/ While this can be argued to be treated as a package bug, I think it would be more flexible and easier to maintain if actually used find_library or such.

Will the compiler/linker selectively include only the corresponding config file from /etc/ in multiarch? Are they hardcoded? In that case, is deprecated?
The wikis doesn't mention at all, even though it should be absolutely vital.

Edit: I apologize for the confused, incorrect statements above. I was confused about the linker behavior. The /etc/ file is not used by the linker and shouldn't be used by CMake either.

Brad King (manager)
2011-06-08 10:30

Re 0012037:0026747: Please try the v1-0f939ee1+000[12]* patch series.
Brad King (manager)
2011-06-08 10:35

Re 0012037:0026756: The export_library_depends command has been superseded by install(EXPORT) and export(): [^] [^]

I believe the new approach is in use in VTK 5.8 (or perhaps 5.10).
Modestas Vainius (reporter)
2011-06-09 03:58

Thank you, Brad. Both patches work (tested on top of 2.8.4). I tested find_library() in the real world. I checked find_package() with strace and it seems like it should work too.

1) These patches also lay down a path for fixing Find* modules. I fixed FindGTK2.cmake like this:

--- a/Modules/FindGTK2.cmake
+++ b/Modules/FindGTK2.cmake
@@ -187,6 +187,7 @@ function(_GTK2_FIND_INCLUDE_DIR _var _hd

However, if ${CMAKE_LIBRARY_ARCHITECTURE} is not set, /usr/lib will be checked twice in a bit wrong order. Could something be improved here (without IFs or moving down /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} above /usr/lib64)?

2) Will those patches be part of 2.8.5? I want to emphasize that released Ubuntu 11.04 (natty) already has this multiarch enabled so upstream cmake up to and including 2.8.4 is basically unusable on those systems. That's because libc6 package is multiarch enabled and e.g. vanilla cmake 2.8.4 is not even able to set CMAKE_DL_LIBS properly.
Brad King (manager)
2011-06-09 13:49

Re 0012037:0026801: Thanks for testing the patches. I merged them to the CMake 'next' branch:;a=commitdiff;h=b41ad3b3 [^];a=commitdiff;h=52a6ed2a [^]

I still need to consult with some other developers to see if this design is acceptable as a permanent solution.

For GTK2 they actually install headers into <prefix>/lib? Are all the headers architecture-specific? How are projects built with other build systems supposed to find the headers? Does it always come with pkgconfig or some kind of gtk2-config script?
Modestas Vainius (reporter)
2011-06-11 06:55

> For GTK2 they actually install headers into <prefix>/lib? Are all the headers
> architecture-specific? [^]

> How are projects built with other build systems supposed to find the headers?
> Does it always come with pkgconfig or some kind of gtk2-config script? [^]

The latter is probably the subject of another bug.
Modestas Vainius (reporter)
2011-06-12 10:42

I have just uploaded regex-update-arm-eabi-kfreebsd-hurd.diff. It contains fixes for v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch:

From: Modestas Vainius <>
Subject: CMAKE_LIBRARY_ARCHITECTURE_REGEX fixes and improvements
Date: Sun, 12 Jun 2011 17:40:01 +0300

* Fix linux CMAKE_LIBRARY_ARCHITECTURE_REGEX to support armel-linux-gnueabi.

Also regex is improved to support quadlets. Even if I have not seen this in the
wild yet, reportedly they are possible.

The patch should be applied on top of
Brad King (manager)
2011-06-13 11:33

Re 0012037:0026834: Thanks. See my entry in the related issue: 0012049:0026848
Brad King (manager)
2011-06-13 11:39

Re 0012037:0026843: Thanks for the patch. Those expressions look good. Applied:;a=commitdiff;h=1ed19bcb [^]
Brad King (manager)
2011-06-14 13:26

I merged the commits mentioned in 0012037:0026809 and 0012037:0026850 to our 'master' branch in preparation for inclusion in the 2.8.5 release.
Alex Neundorf (developer)
2011-07-20 16:18

There is another entry in the tracker, which seems to be related, 0011260.
Is this also fixed with your changes ?

Modestas Vainius (reporter)
2011-07-21 02:25

Multiarch does not have much to do with amd64 biarch (paths are different as multiarch does not use /usr/lib32 or /usr/lib64). Let's not mix there two into one.
Brad King (manager)
2011-07-25 13:20

Agreed. Closing again.

 Issue History
Date Modified Username Field Change
2011-04-03 16:28 Modestas Vainius New Issue
2011-04-04 02:23 Eric NOULARD Note Added: 0026028
2011-04-04 02:23 Eric NOULARD Relationship added related to 0011964
2011-04-04 03:00 Eric NOULARD Note Added: 0026029
2011-04-04 03:01 Eric NOULARD Note Edited: 0026029
2011-04-04 03:03 Eric NOULARD Note Edited: 0026029
2011-04-04 05:31 Modestas Vainius Note Added: 0026032
2011-04-04 06:38 Eric NOULARD Note Added: 0026033
2011-04-06 07:42 Eric NOULARD Relationship added related to 0012049
2011-04-06 11:55 Brad King Note Added: 0026124
2011-04-06 15:43 Modestas Vainius Note Added: 0026126
2011-05-19 16:11 Alex Neundorf Note Added: 0026557
2011-06-07 08:19 Eric NOULARD Relationship added related to 0012247
2011-06-07 08:21 Eric NOULARD Relationship added related to 0012248
2011-06-07 16:15 Brad King Relationship added related to 0012254
2011-06-07 16:28 Modestas Vainius Note Added: 0026743
2011-06-07 16:52 Brad King Note Added: 0026744
2011-06-07 16:57 Brad King Note Added: 0026745
2011-06-07 17:40 Modestas Vainius Note Added: 0026746
2011-06-07 18:20 Modestas Vainius Note Added: 0026747
2011-06-08 08:18 Brad King Relationship replaced has duplicate 0012254
2011-06-08 08:56 Mikael Öhman Note Added: 0026756
2011-06-08 10:11 Brad King Assigned To => Brad King
2011-06-08 10:11 Brad King Status new => assigned
2011-06-08 10:29 Brad King File Added: v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch
2011-06-08 10:30 Brad King File Added: v1-0f939ee1+0002-Test-find_package-multiarch-support-12037.patch
2011-06-08 10:30 Brad King Note Added: 0026761
2011-06-08 10:35 Brad King Note Added: 0026762
2011-06-08 11:44 Mikael Öhman Note Edited: 0026756
2011-06-09 03:58 Modestas Vainius Note Added: 0026801
2011-06-09 13:49 Brad King Note Added: 0026809
2011-06-11 06:55 Modestas Vainius Note Added: 0026834
2011-06-12 10:40 Modestas Vainius File Added: regex-update-arm-eabi-kfreebsd-hurd.diff
2011-06-12 10:42 Modestas Vainius Note Added: 0026843
2011-06-13 11:33 Brad King Note Added: 0026849
2011-06-13 11:39 Brad King Note Added: 0026850
2011-06-14 13:26 Brad King Note Added: 0026855
2011-06-14 13:26 Brad King Status assigned => resolved
2011-06-14 13:26 Brad King Fixed in Version => CMake 2.8.5
2011-06-14 13:26 Brad King Resolution open => fixed
2011-06-14 13:33 Brad King Relationship deleted related to 0012248
2011-06-18 07:40 David Cole Target Version => CMake 2.8.5
2011-07-20 16:18 Alex Neundorf Note Added: 0027058
2011-07-20 16:18 Alex Neundorf Status resolved => feedback
2011-07-20 16:18 Alex Neundorf Resolution fixed => reopened
2011-07-21 02:25 Modestas Vainius Note Added: 0027059
2011-07-21 02:25 Modestas Vainius Status feedback => assigned
2011-07-25 13:20 Brad King Note Added: 0027064
2011-07-25 13:20 Brad King Status assigned => closed
2011-07-25 13:20 Brad King Resolution reopened => fixed
2011-07-25 13:21 Brad King Relationship added related to 0012326
2011-08-29 15:26 Brad King Relationship added related to 0012428
2012-06-18 08:14 Brad King Relationship added related to 0013280
2012-11-26 16:18 Brad King Relationship added related to 0013742

Copyright © 2000 - 2018 MantisBT Team