View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0012037 | CMake | CMake | public | 2011-04-03 16:28 | 2012-11-26 16:18 | ||||
Reporter | Modestas Vainius | ||||||||
Assigned To | Brad King | ||||||||
Priority | high | Severity | major | Reproducibility | N/A | ||||
Status | closed | Resolution | fixed | ||||||
Platform | amd64 | OS | Debian GNU/Linux | OS Version | sid | ||||
Product Version | CMake 2.8.4 | ||||||||
Target Version | CMake 2.8.5 | Fixed in Version | CMake 2.8.5 | ||||||
Summary | 0012037: support multiarch lib paths for Debian/Ubuntu | ||||||||
Description | Debian 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] http://wiki.debian.org/Multiarch [^] [2] https://wiki.ubuntu.com/MultiarchSpec [^] Design -> Filesystem layout section [3] https://bugs.launchpad.net/debian/+source/cmake/+bug/737137 [^] [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618932#5 [^] 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) GET_FILENAME_COMPONENT(_CMAKE_INSTALL_DIR "${CMAKE_ROOT}" PATH) GET_FILENAME_COMPONENT(_CMAKE_INSTALL_DIR "${_CMAKE_INSTALL_DIR}" PATH) +EXECUTE_PROCESS(COMMAND dpkg-architecture -qDEB_HOST_MULTIARCH OUTPUT_VARIABLE CMAKE_ARCH_TRIPLET OUTPUT_STRIP_TRAILING_WHITESPACE) + # List common installation prefixes. These will be used for all # search types. LIST(APPEND CMAKE_SYSTEM_PREFIX_PATH @@ -74,6 +76,7 @@ LIST(APPEND CMAKE_SYSTEM_PROGRAM_PATH ) LIST(APPEND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES + /lib/${CMAKE_ARCH_TRIPLET} /usr/lib/${CMAKE_ARCH_TRIPLET} /lib /usr/lib /usr/lib32 /usr/lib64 ) | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch [^] (15,725 bytes) 2011-06-08 10:29 [Show Content]
v1-0f939ee1+0002-Test-find_package-multiarch-support-12037.patch [^] (5,415 bytes) 2011-06-08 10:30 [Show Content] regex-update-arm-eabi-kfreebsd-hurd.diff [^] (1,881 bytes) 2011-06-12 10:40 [Show Content] | ||||||||
Relationships | |||||||||||||||||||||||||||||||||||||||||
|
Relationships |
Notes | |
(0026028) Eric NOULARD (developer) 2011-04-04 02:23 |
Hi Modestas, We did have related discussion concerning lib64 handling for CPack (RPM) http://www.cmake.org/Bug/view.php?id=11964. [^] 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. |
(0026029) 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. |
(0026032) 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. |
(0026033) 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 INSTALL(... DESTINATION /lib/${APPROPRIATE_DIR}...) may the GNUInstallDirs.cmake module be updated for the multi-arch case? |
(0026124) 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? |
(0026126) 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. |
(0026557) 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. |
(0026743) 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... |
(0026744) 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. |
(0026745) 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. |
(0026746) 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. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper 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: /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed /usr/include End of search list. # 1 "/dev/null" # 1 "<built-in>" # 1 "<command-line>" # 1 "/dev/null" COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/ COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=x86-64' Multiarch paths are also in /etc/ld.so.conf: $ cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf $ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu For example, on i386 there is /etc/ld.so.conf.d/i486-linux-gnu.conf But please note that both (or more) such confs can be installed at the same time (the whole point of multiarch). |
(0026747) 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 (libNAME.so) are never installed to /lib. But maybe this could be treated as bug [1] ... [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618932#34 [^] |
(0026756) 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 ld.so.conf, 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/libld.so), rendering all *Config.cmake files supplied (VTK, Paraview, etc.) broken (they all hardcode /usr/lib/libdl.so). 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/ld.so.conf.d/ in multiarch? Are they hardcoded? In that case, is ld.so.conf deprecated? The wikis doesn't mention ld.so.conf 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/ld.so.conf file is not used by the linker and shouldn't be used by CMake either. |
(0026761) Brad King (manager) 2011-06-08 10:30 |
Re 0012037:0026747: Please try the v1-0f939ee1+000[12]* patch series. |
(0026762) Brad King (manager) 2011-06-08 10:35 |
Re 0012037:0026756: The export_library_depends command has been superseded by install(EXPORT) and export(): http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages [^] http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets [^] I believe the new approach is in use in VTK 5.8 (or perhaps 5.10). |
(0026801) 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 PATHS /usr/local/lib64 /usr/local/lib + /usr/lib/${CMAKE_LIBRARY_ARCHITECTURE} /usr/lib64 /usr/lib /opt/gnome/include 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. |
(0026809) Brad King (manager) 2011-06-09 13:49 |
Re 0012037:0026801: Thanks for testing the patches. I merged them to the CMake 'next' branch: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b41ad3b3 [^] http://cmake.org/gitweb?p=cmake.git;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? |
(0026834) Modestas Vainius (reporter) 2011-06-11 06:55 |
> For GTK2 they actually install headers into <prefix>/lib? Are all the headers > architecture-specific? https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/751940/comments/6 [^] > 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? https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/751940/comments/1 [^] The latter is probably the subject of another bug. |
(0026843) 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 <modax@debian.org> 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. * Add CMAKE_LIBRARY_ARCHITECTURE_REGEX on kFreeBSD. * Add CMAKE_LIBRARY_ARCHITECTURE_REGEX on GNU (Hurd). 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 v1-0f939ee1+0001-Teach-find_-library-package-about-Linux-multiarch-12.patch |
(0026849) Brad King (manager) 2011-06-13 11:33 |
Re 0012037:0026834: Thanks. See my entry in the related issue: 0012049:0026848 |
(0026850) Brad King (manager) 2011-06-13 11:39 |
Re 0012037:0026843: Thanks for the patch. Those expressions look good. Applied: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1ed19bcb [^] |
(0026855) 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. |
(0027058) 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 ? Alex |
(0027059) 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. |
(0027064) Brad King (manager) 2011-07-25 13:20 |
Agreed. Closing again. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |