|
Notes |
|
|
(0027279)
|
|
don la dieu
|
|
2011-08-28 15:10
|
|
|
Mistaken about 2.8.3. I was using the system version of cmake. A clean 2.8.3 fails in the same way. |
|
|
|
(0027281)
|
|
Brad King
|
|
2011-08-29 10:08
|
|
Multiarch support was added in 2.8.5, so any earlier version will fail on all compilers.
CMake uses this regex to detect the architecture triplet from the list of implicit link directories detected from the compiler:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/Platform/Linux.cmake;hb=v2.8.5#l48 [^]
SET(CMAKE_LIBRARY_ARCHITECTURE_REGEX "[a-z0-9_]+(-[a-z0-9_]+)?-linux-gnu[a-z0-9_]*")
Please post the CMakeFiles/CMake*Compiler.cmake files from the build tree too. They contain the detected implicit link directories, if any. |
|
|
|
(0027283)
|
|
don la dieu
|
|
2011-08-29 12:39
|
|
|
The CMAKE_${lang}_IMPLICIT_LINK_DIRECTORIES are set to "/opt/ekopath-4.0.11/lib/4.0.11/x8664/64" |
|
|
|
(0027284)
|
|
don la dieu
|
|
2011-08-29 12:48
|
|
|
FWIW I included Ubuntu's multiarch path patch to 2.8.3. Unfortunatly the call to dpkg-architecture limits its utility. |
|
|
|
(0027286)
|
|
Brad King
|
|
2011-08-29 12:53
|
|
Re 0012428:0027283: That implicit link directory list does not include any multiarch directories. That's why CMake doesn't detect the library architecture triplet.
Please also attach the CMakeOutput.log and CMakeError.log from the CMakeFiles directory. They should contain more information about the implicit link directory detection process. |
|
|
|
(0027288)
|
|
don la dieu
|
|
2011-08-29 13:15
|
|
|
There's no CMakeFiles/CMakeError.log with that example project |
|
|
|
(0027290)
|
|
Brad King
|
|
2011-08-29 13:25
|
|
The log file shows that CMake correctly found the link line:
/usr/bin/ld --hash-style=gnu --eh-frame-hdr -demangle -v --dynamic-linker=/lib64/ld-linux-x86-64.so.2 -rpath /opt/ekopath-4.0.11/lib/4.0.11/x8664/64 -melf_x86_64 -L/opt/ekopath-4.0.11/lib/4.0.11/x8664/64 -o cmTryCompileExec /usr/lib/crt1.o /usr/lib/crti.o /opt/ekopath-4.0.11/lib/4.0.11/x8664/64/crtbegin.o CMakeFiles/cmTryCompileExec.dir/CMakeCXXCompilerABI.cpp.o -lstl -lcxxrt -lpthread -ldl -lm -lgcc -leh -lc /opt/ekopath-4.0.11/lib/4.0.11/x8664/64/crtend.o /usr/lib/crtn.o -lpscrt -lmv -lmpath -lc
and parsed it. However the line does not contain any system directories like /usr/lib or /usr/lib/<arch>. I wonder how the compiler convinces the linker to find such system libraries. What is in /opt/ekopath-4.0.11/lib/4.0.11/x8664?
Do you know any way to convince this toolchain to report the library architecture directories like /usr/lib/<arch>? Does the compiler itself support multiarch? |
|
|
|
(0027291)
|
|
don la dieu
|
|
2011-08-29 15:15
|
|
|
GNU binutils has the system directories compiled into it. pathcc relies on that behavior. gcc passes the system directories as a convenience so that you can drop in other linkers that are "command line compatible". |
|
|
|
(0027292)
|
|
don la dieu
|
|
2011-08-29 15:17
|
|
[maru:~] PATH=/opt/ekopath-4.0.11/bin pathcc -print-search-dirs
install: /opt/ekopath-4.0.11
programs: /opt/ekopath-4.0.11/bin:/opt/ekopath-4.0.11/lib/4.0.11/x8664
libraries: /opt/ekopath-4.0.11/lib/4.0.11/x8664/64:/lib64:/usr/lib64 |
|
|
|
(0027294)
|
|
Brad King
|
|
2011-08-29 15:24
|
|
Re 0012428:0027291: That is good to know, thanks.
Re 0012428:0027292: I don't see the architecture triplet anywhere in those paths :(
Does binutils provide a standard way to get the triplet? How is anyone supposed to know where to install things if there is no easy way to get the triplet? |
|
|
|
(0027298)
|
|
don la dieu
|
|
2011-08-29 16:58
|
|
No, as multiarch is unrelated to binutils, gcc and GNU in general. It's a packaging standard for Debian (and derivitives) that was partly derived from how gcc handled its internal layout for dealing with cross-compilers. All the gory details are here: http://wiki.debian.org/Multiarch. [^]
On a multiarch aware system the triplet can be retrieved with dpkg-architecture.
[maru:~] dpkg-architecture -qDEB_HOST_MULTIARCH
x86_64-linux-gnu
When bundling .deb's of libraries, this is take care of by debhelper (I think. I only glanced at that part of the docs.)
Since this is really a Debian (and derivitives) issue, maybe a patch similar to the Ubuntu one I provided is the way to go. Or, test this at configure/build time of cmake itself. |
|
|
|
(0027299)
|
|
Brad King
|
|
2011-08-29 17:04
|
|
See the discussion in 0012037. The dpkg-architecture tool might not be available. Also, if the compilation targets a different architecture than the host then the answer it dpkg-architecture provides is wrong.
We need to detect the triplet from the toolchain for its target architecture. GCC provides a way to do it. We need to find a way to do it with PathScale too. |
|
|
|
(0027300)
|
|
don la dieu
|
|
2011-08-29 20:21
|
|
|
Ah! Of course. I was just focused on $host == $target. Anything else would obviously break. I'll poke a bit harder at it, though I might not be able to for a few days. |
|
|
|
(0030341)
|
|
David Cole
|
|
2012-08-11 21:09
|
|
Sending old, never assigned issues to the backlog.
(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)
If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]
It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
|
|
|
|
(0031332)
|
|
don la dieu
|
|
2012-10-25 16:32
|
|
Hacky, but it gets the job done
--- CMake/Modules/CMakeParseImplicitLinkInfo.cmake 2011-08-31 12:30:44.000000000 -0400
+++ cmake-2.8.8/Modules/CMakeParseImplicitLinkInfo.cmake 2012-10-25 16:03:03.113455792 -0400
@@ -52,6 +52,14 @@
string(REGEX REPLACE "^-L" "" dir "${arg}")
list(APPEND implicit_dirs_tmp ${dir})
set(log "${log} arg [${arg}] ==> dir [${dir}]\n")
+ ## pathscale on linux helper
+ elseif("${arg}" MATCHES "/crt1.o$")
+ string(REGEX REPLACE "/crt1.o$" "" dir "${arg}")
+ list(APPEND implicit_dirs_tmp ${dir})
+ set(log "${log} arg [${arg}] ==> dir [${dir}] PEWP\n")
+ string(REGEX REPLACE "^/usr" "" dir "${dir}")
+ list(APPEND implicit_dirs_tmp ${dir})
+ set(log "${log} arg [${arg}] ==> dir [${dir}] PEWP\n")
elseif("${arg}" MATCHES "^-l[^:]")
# Unix library.
string(REGEX REPLACE "^-l" "" lib "${arg}") |
|
|
|
(0031335)
|
|
Brad King
|
|
2012-10-25 16:47
|
|
Re 0012428:0031332: The crt1.o shown in your log line I extracted and reported in 0012428:0027290 does not sit in an architecture-triplet directory. How does this match help?
How do other projects detect the proper triplet for this compiler? |
|
|
|
(0041896)
|
|
Kitware Robot
|
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|
CMakeLists.txt (619) 2011-08-28 15:00
CMakeCCompiler.cmake (1,348) 2011-08-29 12:35