View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011964CMakeCPackpublic2011-03-13 04:442011-06-17 18:40
ReporterEric NOULARD 
Assigned ToEric NOULARD 
PlatformLinuxOSany x86_64OS Version
Product VersionCMake 2.8.4 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0011964: Handle lib64 library on Linux
DescriptionOpenSUSE contains an RPM policy implemented
in /usr/lib/rpm/brp-lib64-linux
which seems to be annoyed by current CPackRPM.

see: [^]
and [^]
and [^]
Additional InformationInitial report name was: CPackRPM fails on OpenSUSE x86_64 (64 bits).
TagsNo tags attached.
Attached Files

related to 0012037closedBrad King support multiarch lib paths for Debian/Ubuntu 
related to 0012253closedEric NOULARD CPack RPM generator self dependency trouble 

Eric NOULARD (developer)
2011-03-13 16:24

I did try a blind fix with this commit:

Merge topic 'CPackRPM-TestWithMoreTraces' into next
a201028 CPack try to please SUSE 64 bits and install lib in lib64 and not lib.
Eric NOULARD (developer)
2011-03-13 18:17

Looks like the lib vs lib64 thing is written in:

A.1 Execution of 32-bit Programs
The AMD64 processors are able to execute 64-bit AMD64 and also 32-bit ia32
programs. Libraries conforming to the Intel386 ABI will live in the normal places
like /lib, /usr/lib and /usr/bin. Libraries following the AMD64, will
use lib64 subdirectories for the libraries, e.g /lib64 and /usr/lib64. Pro-
grams conforming to Intel386 ABI and to the AMD64 ABI will share directories
like /usr/bin. In particular, there will be no /bin64 directory.

And it looks like Debian did not follow the rule: [^]
Eric NOULARD (developer)
2011-03-13 18:19

Copy/Paste message from ML, as a reminder.

On my Debian 64 bits box I have:

$ ls -ld /usr/lib*
drwxr-xr-x 311 root root 151552 12 mars 23:30 /usr/lib
drwxr-xr-x 33 root root 45056 29 janv. 10:18 /usr/lib32
lrwxrwxrwx 1 root root 3 31 déc. 2008 /usr/lib64 -> lib
drwxr-xr-x 3 root root 4096 1 janv. 2009 /usr/libexec

As you can see /usr/lib is the 'native' lib dir, with lib64 being a
link to this.
Then lib32 is the 32bits 'non-native' one.
This layout seems reasonable, I'll check on Fedora 64 or other RPM based
distros during this week.

Now I may teach CPackRPM to detect if it is running on Fedora or SUSE
or Mandriva etc..
and do some nasty things like renaming lib destination into lib64
if we are packaging a 64 bit package but I currently find it weird.

The rpm installer (the rpm command) or packager (rpmbuild) perfectly knows
that we are building a natively 64 bits RPM package it's even written in the RPM
using "Architecture" field so if he wants to enforce to put 64 bits
libs into lib64
he may do it by itself and not asking the packager to do it.

Currently I would say that rpm build policy on SUSE 64 bits
is the culprit not CPackRPM (which is simply calling RPM build).

However, I'll investage further because up to now I did never face
such 32/64 bits issue
even if I use natively 64 bits linux systems since at least 5 years...

Slackware seems to be using lib${LIBDIRSUFFIX} [^]

Others (like at least Fedora, RedHat, Mandriva)
seems to be using builtin RPM "%_libdir" macros.

The thing is currently with cpack the user chose the library/runtime
so if he chose 'lib' shall we go with "lib64" should be safe but
if the installation prefix is not '/usr' but '/opt/' or '/anywhere/you/want'
shall we do the lib-->lib64 automatic renaming.

Any insight or reference about this 32/64 bits lib mixup is welcomed.
Rolf Eike Beer (developer)
2011-03-14 03:42

Gentoo also has a link lib -> lib64, at least on my AMD64-nomultilib installations.

Ideally this would not be part of the CPack stuff, but only used by it so things like that would just do the right thing:

Eric NOULARD (developer)
2011-03-14 07:49

I've done some verification all the following 64 bits distribution
 - OpenSUSE Linux 11.4
 - Fedora Core 14
 - Mandriva 2010.2

do have separate:
  /usr/lib --> for 32 bits libs
  /usr/lib64 --> for 64 bits libs
this is the same for
  /lib and /lib64
  /usr/local/lib and /usr/local/lib64

so since other distro (at least debian based and gentoo) do have
a link lib-->lib64, it should be safe to always install lib
in lib64 if the package is a 64 bits package.
Marcel Loose (developer)
2011-03-14 08:18

There is this IMHO weird ambiguity in CMake between find_library() that uses lib64 to search for libraries (if FIND_LIBRARY_USE_LIB64_PATHS is TRUE), and install() that only installs in lib64 if you explicitly specify 'lib64' as DESTINATION. I don't know if this is somehow related to the CPackRPM issue, though.
Eric NOULARD (developer)
2011-03-14 08:59

Hi Marcel,
Where is the "FIND_LIBRARY_USE_LIB64_PATHS" variable documented?
Is it defined by CMake or should the user define it?

I think , I'll soon recast this bug into something
wider than the CPackRPM concerns.

In fact if the majority of 64bits linux distros
and x86-64 ABI document advocate the use of 'lib64'
for 64bits libs and 'lib' for 32bits ones then
CMake should provided a way to **automatically** install
libraries in lib for 32bits and lib64 for 64bits.

I imagine (at least) 2 differents solutions:

A) This could be a new
   CMAKE_LIBDIR_NAME var which could be set by CMake
   and then used in install command (as suggested by Eike).

B) Or alternatively CMAKE_LIBDIR_SUFFIX
   which would be added to the
   this could be used by find_library too.

Now B) can be set by CMake or set/overriden by the user.
CMake may at least do it by itself

When CMAKE_LIBDIR_SUFFIX is set (by CMake or by the User)
[and we are not cross-compiling]
the install generator could be made smart enough to
replace "lib[/whatever]" relative path by

What do you think?
Marcel Loose (developer)
2011-03-14 10:57

"FIND_LIBRARY_USE_LIB64_PATHS is a global scope property. It is defined by CMake, but the user may override it (if she so desires).

I think I favor option B). It feels a bit cleaner and matches with the use of CMAKE_*_LIBRARY_SUFFIX.

It does need some tweaking of the C++ implementation as well, because the current cmFindLibraryCommand.* and cmFindPackageCommand.* already do some name juggling of lib<->lib64 depending on whether FIND_LIBRARY_USE_LIB64_PATHS is set or not.
Eric NOULARD (developer)
2011-03-14 16:15

What should we use for CMAKE_LIBDIR_SUFFIX
should we use a property or a variable?
Rolf Eike Beer (developer)
2011-03-15 02:12

I think a variable would be best, otherwise you always need to query the property before doing INSTALL(TARGET foo DESTINATION ...).

And for the cross compiling case we need that to be set to lib32 on those platforms where it is needed (like your Debian).

The other version would be that the value of that property would override every target destination given as "lib" when CMAKE_LIBRARY_PATH_LIB_OVERRIDE set to true (or whatever) but I think that is not very intuitive.
Marcel Loose (developer)
2011-03-15 04:12

IMO a global property would be more logical, because there's already a FIND_LIBRARY_USE_LIB64_PATH property. A new property INSTALL_LIBRARY_USE_LIB64_PATH could be defined for this. You normally don't want to override this setting, so it could be defined by of CMake's initialization modules. Or maybe it should be a shorter, more general property name, like CMAKE_USE_LIB64_PATH.
Eric NOULARD (developer)
2011-03-15 05:25

I think that the property idea is meant to be "automatic".
If CMake (or the user) does:


then CMake will append this suffix for any ARCHIVE or LIBRARY
destination found in

install(TARGETS myExe mySharedLib myStaticLib
                   RUNTIME DESTINATION bin
                   LIBRARY DESTINATION lib
                   ARCHIVE DESTINATION lib/static)

which would transparently (for the user) became

install(TARGETS myExe mySharedLib myStaticLib
                   RUNTIME DESTINATION bin
                   LIBRARY DESTINATION lib64
                   ARCHIVE DESTINATION lib64/static)

now since this should only be done on linux x86_64
for a limited set of directories:
(.*)/lib[/(.*)]* -> (.*)/lib64[/(.*)]*

so we could even do:
set_property(GLOBAL PROPERTY
             CMAKE_LIBRARY_DESTINATION_REPLACE "(.*)/lib[/(.*)]*;(.*)/lib64[/(.*)]*")
set_property(GLOBAL PROPERTY
             CMAKE_ARCHIVE_DESTINATION_REPLACE "(.*)/lib[/(.*)]*;(.*)/lib64[/(.*)]*")

but may be
could be simpler and more appropriate.

The suffix idea is more versatile but I don't really know if it is
not just simply overkilling the need.

I think we want to do this somehow "globally" because I cannot
(but I may be wrong) imagine someone wanting to do that for one lib
and not for the other.

Marcel Loose (developer)
2011-03-15 06:02

Yes, I think too that this should be a global property. My idea is also that the lib vs. lib64 handling is done transparently to the user, just like Eric wrote. I think having a user-definable suffix is overkill; personally I don't see any use for it.

Most of this behind-the-scenes stuff should be implemented in the C++ part, I guess.
Rolf Eike Beer (developer)
2011-03-15 10:57

That still leaves the question: how would that work when building 32 bit libraries on 64 bit Debian then? As /lib/ should be replaced by /lib32/ then to be consistent.
Eric NOULARD (developer)
2011-03-15 11:13

Building 32bits on a native 64bits is somehow cross-compiling.
I'll think about it.

How do you to build 32bits on debian (or other) 64bits distro?
Do you manually add "-m32" ?
Eric NOULARD (developer)
2011-03-15 14:28

Some more refs about Debian choice for multiarch: [^] [^]
Eric NOULARD (developer)
2011-03-19 10:40

I've just merged a fix on next.
Merge topic 'linux-lib64-handling' into next
d515479 fix 0011964 withe the use of a new CMAKE_USE_LIB64_PATH property

I did use a new global property:
When this property is true then the path found in
are mangled by replacing occurrence of 'lib' by 'lib64'.
It is done in 3 differents contexts:
so that 'librarian' won't be renamed to 'lib64brarian'.

The property is automatically set by CMake:
  - FALSE is the default value on UnixPaths.cmake
  - TRUE in Linux.cmake if we are on a x86_64 system
    but not on Debian based systems

The property may be overriden by the user in its CMakeLists.txt.
Eric NOULARD (developer)
2011-03-19 10:41

I think the issue is resolved even if we will have
to handle the "32 bits" on "64bits" debian system case.
I think this is a kind of cross-compilation case which needs
to be discussed separately.
Eric NOULARD (developer)
2011-03-19 10:42

See previous comment.
Brad King (manager)
2011-03-22 15:29

Reopening due to SimpleInstall test trouble.
Brad King (manager)
2011-03-22 15:33

The design of this is not yet mature enough even for 'next'. I reverted it:;a=commitdiff;h=ca7ee675 [^];a=commitdiff;h=2ada3c64 [^]
Brad King (manager)
2011-03-22 15:51

Since I reverted the original commits you'll have to rebase and rewrite them to publish them again. We'll review and discuss this feature here. Please push future versions to the stage but do not merge them to next until we're done.

The corresponding property for find_library is called "FIND_LIBRARY_USE_LIB64_PATHS". This one affects the install() commands so it should be called "INSTALL_USE_LIB64_PATHS".

Further comments may follow.
Brad King (manager)
2011-03-22 16:02

I see no reason to do this only for ARCHIVE and LIBRARY destinations. A RUNTIME file may be installed in lib/myproj if it is a private helper executable. Do it for all destination types.

In DoMangleLibDestination consider using cmSystemTools::SplitPath, then transform each component as lib->lib64 trivially, and then use JoinPath to recombine the destination.
Brad King (manager)
2011-03-22 16:12

Unlike the find_library command whose result can easily be overridden by a cache entry, this feature introduces a major change in behavior for existing code on existing platforms. Other than an obscure test failure and a semi-standard design document is there any reason to enable this by default? Ideally all applications should allow their destinations to be configured. This magic lib->lib64 transformation is nice to help the switch all destinations at once. However, it will also lead to surprising behavior like:

  $ cat CMakeLists.txt
  install(... DESTINATION lib)
  $ make install
  Installing .../lib64/...
  $ wtf?
Marcel Loose (developer)
2011-03-23 04:41

And another note of caution. If you're "cross-compiling" a 32-bit application on a 64-bit RedHat-like system, you DON'T want the libraries to be installed in lib64, but in lib. Ditto for Debian-like systems; there you want the libraries to be installed in lib32.
Eric NOULARD (developer)
2011-03-23 09:12

Hi Brad and Marcel,

Thank you Brad for re-opening this.
I should have re-opened it but I wasn't able to access the tracker at that time.
I was clearly too confident for this patch.
I won't push it to next until we are OK.

Concerning the "magic" aspect, you may be right
I'm beginning to think that this may not be
a good goal to achieve "total" transparency.

May be we could just:

1) Guess for any system the "preferred" LIBDIR and
   set a new variable
   that would evaluate to lib, lib32 or lib64 or whatever.

2) Let the user use this variable in its INSTALL rules or not.

3) Make some enhancement in concerned CPack generators
   (mainly CPackRPM and CPackDeb) in order to spit out a warning
   (or an error) when 'lib' is used where Linux system standard
   expects lib64, lib32, libWhatever...

As you mentioned the black magic of the behind the scene rename
may simply be too cryptic.

Concerning the 32bits compile on 64bits systems I continue to think
that this is a kind of cross-compiling. If it's not and we expect
to be able to build both 32 and 64 bits executables/lib in the same
tree we could define a
Marcel Loose (developer)
2011-03-23 09:52

Hi Eric,

I would prefer a property like INSTALL_LIBRARY_USE_LIB64_PATH, to be more in line with FIND_LIBRARY_USE_LIB64_PATH.

I don't mind a bit of under-the-hood smartness. As a user, I would expect find_library() and install() to behave similarly when it comes to handling library paths. At the moment, that is not the case.

So, if we decide to add a property like INSTALL_LIBRARY_USE_LIB64_PATH, then it could be initialized to the same value as INSTALL_LIBRARY_USE_LIB64_PATH. The install() command should always honor the value of INSTALL_LIBRARY_USE_LIB64_PATH. Advantage of this automatic library path handling is that the user doesn't have to remember to set this variable when on RedHat-like systems (something he might very well forget).

W.r.t. compiling 32-bit code on a 64-bit system: you may be right that this should be considered cross-compilation. My guess is that find_library() will also fail in these cases, unless you explicitly tell CMake that you're doing cross-compilation (though Brad may prove me wrong).
Eric NOULARD (developer)
2011-03-23 10:51

Hi Marcel,

I'm basically OK with the fact that INSTALL_LIBRARY_USE_LIB64_PATH
and FIND_LIBRARY_USE_LIB64_PATH should be set to coherent values
and/or be tight together in some way (e.g.setting one this to TRUE
implies the other is true too), or simply use FIND_LIBRARY_USE_LIB64
as an indication for INSTALL to behave likewise.

Now the main difference between find_library and install is,
as stated by Brad, is that find library gives you a result you
may perfectly override. If install is doing nasty renaming behind
you back you may be bitten by unexpected effect.

Have look at what is done by Tests/SimpleInstall and Tests/SimpleInstallS2
and you'll soon discover that there is a wealth of way to break
and automated lib->lib64 renaming.

For example I'm not a MacOS user but this var CMAKE_INSTALL_NAME_DIR
may give us some trouble,
I know the lib64 thing shouldn't be activated on MacOS, but I'm not
sure to have examined all possible VAR-configured or PROPERTY-tunable
lib-related features offered by CMake.

As Brad said if the user expect to find the lib in
then he may do something like (taken from SimpleInstall test)
# Make sure the test executable can run from the install tree.

and it will fail because the lib has been installed in

Now we should automatically track:
 - INSTALL_RPATH target properties
 - CMAKE_INSTALL_RPATH variable value
 - ... what else
   have a look at [^]
   and tell me there is no other possible interaction.

Basically the "automatic" behavior will certainly be ok for
mainstream non-exotic installation & packaging and will
fail with subtle black magic interaction in other cases.

I'm not sure I want to:
   1) take time to seek every possible interaction
   2) maintain that in the long term

The main reason is that in a may-be-not-to-far-away future,
the situation may even be more complicated: [^]

So in the end offering the average user to
**explicitely** use sensible default value computed by CMake
for libdir in it install rule seem enough.

Afterwards if people want to use fancy non-standard
library install location, they could do it as well.
I don't want them to begin to file bug-report because
the automated CMake behavior broke their scheme.

What do you think?
Brad King (manager)
2011-03-23 14:27

Re 0011964:0025884: Great summary, Eric. I agree that the easiest solution is simply to provide a "preferred" library directory name computed based on the target platform of the build. Project code can then use this as the default wherever it might otherwise have used "lib". It is then up to the project to use it consistently.

This actually overlaps with issue 0003976 whose contributed patch I've been meaning to tweak and accept (0003976:0025620).
Brad King (manager)
2011-03-23 14:48

Take a look at the new GNUInstallDirs module I just merged to next:;a=blob;f=Modules/GNUInstallDirs.cmake;hb=c2bf48ef [^]

Perhaps the defaults can be set according to target-specific settings to address this issue.
Marcel Loose (developer)
2011-03-24 06:26

That looks good. If indeed these variables will be set to sensible defaults, also and especially for the lib/lib64 issue, then AFAIC this issue is solved. It might be that I'm overlooking things, since I've never really delved into the intricacies of building packages with CPack, like Eric did, and I've never developed for Mac OS with its multi-arch binaries.
Eric NOULARD (developer)
2011-03-25 17:22

Hi All,

Thank you Brad.
I did have a look at 0003976.
It looks reasonable to put the lib64 default into this module.
Since the module may be loaded even if C is not enabled [yet]
I shall add the same logic I added in Linux.cmake in the immature patch
in order to check whether if we are on a Linux non-debian 64 bit host.
set(CMAKE_INSTALL_LIBDIR "lib64" etc...

I'll try that by the end of the week-end or next week.
Brad King (manager)
2011-03-25 17:31

Eric, I think it is reasonable to demand that languages be enabled before including this file if authors want this behavior. You could simply check to make sure at least one language is available and CMAKE_SIZEOF_VOID_P has been set and warn if not.
Eric NOULARD (developer)
2011-03-26 10:05

Hi Brad,

I've pushed this second try to stage/linux-lib64-handling-v2:
 * [new branch] HEAD -> linux-lib64-handling-v2

Would you like to test it on your side before I merge to next?
This time it should be harmless unless it is used.
I did use it in Tests/CPackComponentForAll however I do not
have any non-debian linux 64 bits hosts at hand to testdrive it.

I may have one on monday at work but I'm not sure I'll have time
to do it.
Brad King (manager)
2011-03-28 09:07

Thanks for working on this, Eric. Good start. I have a couple comments on the current patch (410f4c7f).

(1) The message(WARNING) should be message(AUTHOR_WARNING) because it is the project author that made a mistake.

(2) Please write a more descriptive commit message. Someone reading that in 2 years will have no idea what "second try" means. Describe the change and its motivation as if you were writing high-level instructions for someone else to write the patch.

(3) In order to base work on a topic that is in next but not master, do one of these:

  git checkout -b linux-lib64-handling stage/gnu-install-dirs-issue-3976

or if you also need to base it on something in master that was merged since the topic started:

  git branch gnu-install-dirs-issue-3976 stage/gnu-install-dirs-issue-3976
  git checkout -b linux-lib64-handling origin/master
  git merge gnu-install-dirs-issue-3976
  git branch -d gnu-install-dirs-issue-3976

The commit message created by this type of merge should not mention the 'stage' at all.
Eric NOULARD (developer)
2011-03-28 15:22

Hi Brad,

The new 'linux-lib64-handling' branch should follow your advices,
I have just pushed it:
 * [new branch] HEAD -> linux-lib64-handling

I may merge it to next if you are OK (or you may do it yourself).
Be warned I cannot test this on my computer so it may be worth
a try on non-debian 64bits host before merging.
Eric NOULARD (developer)
2011-03-28 15:26

By the way I removed the buggy branch from stage.
Eric NOULARD (developer)
2011-03-29 05:48

I just tested the new linux-lib64-handling
on a 64bits OpenSUSE 11.4 box
and it works as expected.
Moreover all the CMake tests passed
(including previously failing SimpleInstall*)
which is logical because the current patch does not
change the behavior unless one uses GNUInstallDirs.cmake :-]
Brad King (manager)
2011-03-31 13:36

Re 0011964:0025949:

This is good, except for one bug. You can't use the FORCE option to override the default because that will run every time. We still need to honor any user-set value in the cache. The typical way to choose a default dynamically for a CACHE entry is this:

  set(_LIBDIR_DEFAULT "lib")
    set(_LIBDIR_DEFAULT "lib64")
Brad King (manager)
2011-03-31 13:40

FYI, today we merged the GNUInstallDirs module topic to master. I rebased the linux-lib64-handling topic on the new master and pushed it back to the stage to simplify the history shape. Please fetch that topic and rewrite it to address 0011964:0025988.
Eric NOULARD (developer)
2011-03-31 14:21


Sorry for CACHE FORCE misuse, I'm not using CACHE entry so much.

Should be ok now:
   ce7e686..268502a linux-lib64-handling -> linux-lib64-handling
Eric NOULARD (developer)
2011-03-31 14:23

By the way,
I did not merge it to next in order to let you have a last look :-)
Brad King (manager)
2011-03-31 14:49

Great, thanks. I squashed the fix in with the original commit, combined one level of if() tests, and clarified the error message. Then I merged to 'next':;a=commitdiff;h=126c993d [^]

 Issue History
Date Modified Username Field Change
2011-03-13 04:44 Eric NOULARD New Issue
2011-03-13 04:44 Eric NOULARD Status new => assigned
2011-03-13 04:44 Eric NOULARD Assigned To => Eric NOULARD
2011-03-13 16:24 Eric NOULARD Note Added: 0025765
2011-03-13 18:17 Eric NOULARD Note Added: 0025766
2011-03-13 18:19 Eric NOULARD Note Added: 0025767
2011-03-14 03:42 Rolf Eike Beer Note Added: 0025768
2011-03-14 07:49 Eric NOULARD Note Added: 0025771
2011-03-14 08:18 Marcel Loose Note Added: 0025772
2011-03-14 08:59 Eric NOULARD Note Added: 0025773
2011-03-14 10:57 Marcel Loose Note Added: 0025775
2011-03-14 16:15 Eric NOULARD Note Added: 0025776
2011-03-14 16:16 Eric NOULARD OS Open SUSE x86_64 => any x86_64
2011-03-14 16:16 Eric NOULARD OS Version 11.0 and up =>
2011-03-14 16:16 Eric NOULARD Target Version => CMake 2.8.5
2011-03-14 16:16 Eric NOULARD Summary CPackRPM fails on OpenSUSE x86_64 (64 bits) => Handle lib64 library on Linux
2011-03-14 16:16 Eric NOULARD Additional Information Updated
2011-03-15 02:12 Rolf Eike Beer Note Added: 0025778
2011-03-15 04:12 Marcel Loose Note Added: 0025779
2011-03-15 05:25 Eric NOULARD Note Added: 0025780
2011-03-15 06:02 Marcel Loose Note Added: 0025781
2011-03-15 10:57 Rolf Eike Beer Note Added: 0025785
2011-03-15 11:13 Eric NOULARD Note Added: 0025786
2011-03-15 14:28 Eric NOULARD Note Added: 0025789
2011-03-19 10:40 Eric NOULARD Note Added: 0025829
2011-03-19 10:41 Eric NOULARD Note Added: 0025830
2011-03-19 10:42 Eric NOULARD Note Added: 0025831
2011-03-19 10:42 Eric NOULARD Status assigned => resolved
2011-03-19 10:42 Eric NOULARD Fixed in Version => CMake 2.8.5
2011-03-19 10:42 Eric NOULARD Resolution open => fixed
2011-03-22 15:29 Brad King Note Added: 0025865
2011-03-22 15:29 Brad King Status resolved => feedback
2011-03-22 15:29 Brad King Resolution fixed => reopened
2011-03-22 15:33 Brad King Note Added: 0025866
2011-03-22 15:34 Brad King Status feedback => assigned
2011-03-22 15:34 Brad King Fixed in Version CMake 2.8.5 =>
2011-03-22 15:51 Brad King Note Added: 0025867
2011-03-22 16:02 Brad King Note Added: 0025869
2011-03-22 16:12 Brad King Note Added: 0025870
2011-03-23 04:41 Marcel Loose Note Added: 0025878
2011-03-23 09:12 Eric NOULARD Note Added: 0025881
2011-03-23 09:52 Marcel Loose Note Added: 0025883
2011-03-23 10:51 Eric NOULARD Note Added: 0025884
2011-03-23 14:27 Brad King Note Added: 0025888
2011-03-23 14:48 Brad King Note Added: 0025890
2011-03-24 06:26 Marcel Loose Note Added: 0025894
2011-03-25 17:22 Eric NOULARD Note Added: 0025909
2011-03-25 17:31 Brad King Note Added: 0025910
2011-03-26 10:05 Eric NOULARD Note Added: 0025912
2011-03-28 09:07 Brad King Note Added: 0025921
2011-03-28 15:22 Eric NOULARD Note Added: 0025946
2011-03-28 15:26 Eric NOULARD Note Added: 0025947
2011-03-29 05:48 Eric NOULARD Note Added: 0025949
2011-03-31 13:36 Brad King Note Added: 0025988
2011-03-31 13:40 Brad King Note Added: 0025989
2011-03-31 14:21 Eric NOULARD Note Added: 0025990
2011-03-31 14:23 Eric NOULARD Note Added: 0025991
2011-03-31 14:49 Brad King Note Added: 0025992
2011-03-31 14:49 Brad King Status assigned => closed
2011-03-31 14:49 Brad King Resolution reopened => fixed
2011-04-04 02:23 Eric NOULARD Relationship added related to 0012037
2011-06-07 08:18 Eric NOULARD Relationship added related to 0012247
2011-06-08 04:11 Eric NOULARD Relationship added related to 0012253
2011-06-14 13:35 Brad King Relationship added related to 0012248
2011-06-14 13:37 Brad King Relationship deleted related to 0012248
2011-06-14 13:38 Brad King Relationship deleted related to 0012247
2011-06-17 18:40 David Cole Fixed in Version => CMake 2.8.5

Copyright © 2000 - 2018 MantisBT Team