[cmake-developers] [CMake 0015699]: Link project to custom libc version installed in /opt without bothering system

2015-08-16 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=15699 
== 
Reported By:pavel.odintsov
Assigned To:
== 
Project:CMake
Issue ID:   15699
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-08-16 07:07 EDT
Last Modified:  2015-08-16 07:07 EDT
== 
Summary:Link project to custom libc version installed in
/opt without bothering system
Description: 
Hello, folks!

I'm trying to build my application project which links to custom libc version
installed in /opt.

I have installed glibc 2.22 and gcc 5.2.2 in /opt.

And I have following cmake file:

cmake_minimum_required (VERSION 2.8)

project(MyProject)

# Run this code this way:
# cd build
# cmake -DCMAKE_C_COMPILER=/opt/gcc520/bin/gcc
-DCMAKE_CXX_COMPILER=/opt/gcc520/bin/g++ ..

set(CMAKE_BUILD_TYPE Release)

set(CMAKE_C_COMPILER /opt/gcc520/bin/gcc)
set(CMAKE_CXX_COMPILER /opt/gcc520/bin/g++)

# Remove all standard path's
set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES )
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES )
set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES )

# Specify path's to custom compiled gcc and glibc
set(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES stdc++;gcc;gcc_s;m;c)
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES /opt/glibc_2.22/include)
set(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
/opt/glibc_2.22/lib;/opt/gcc520/lib64;/opt/glibc_2.22/lib;/opt/gcc520/lib/gcc/x86_64-unknown-linux-gnu/5.2.0)

set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} -std=c++11)

# Specify custom ld-linux dynamic linker path
set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE}
-Wl,--dynamic-linker=/opt/glibc_2.22/lib/ld-linux-x86-64.so.2)

# Specify full RPATH for build tree
SET(CMAKE_SKIP_BUILD_RPATH  FALSE)

# Create builds in current folder with install RPATH
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)

SET(CMAKE_INSTALL_RPATH /opt/gcc520/lib64;/opt/glibc_2.22/lib)

add_executable(suxx suxx.cpp)

So when I'm running this manifest it still uses system includes/libraries. But
It should not do it.

I could offer strace of make command here:

strace -s 1024 -f -etrace=execve make
execve(/usr/bin/make, [make], [/* 24 vars */]) = 0
Process 13613 attached
[pid 13613] execve(/usr/bin/cmake, [/usr/bin/cmake,
-H/root/cmake_custom_libc, -B/root/cmake_custom_libc/build,
--check-build-system, CMakeFiles/Makefile.cmake, 0], [/* 27 vars */]) = 0
[pid 13613] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13613, si_uid=0,
si_status=0, si_utime=1, si_stime=0} ---
Process 13614 attached
[pid 13614] execve(/usr/bin/cmake, [/usr/bin/cmake, -E,
cmake_progress_start, /root/cmake_custom_libc/build/CMakeFiles,
/root/cmake_custom_libc/build/CMakeFiles/progress.marks], [/* 27 vars */]) = 0
[pid 13614] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13614, si_uid=0,
si_status=0, si_utime=0, si_stime=0} ---
Process 13615 attached
[pid 13615] execve(/usr/local/sbin/make, [make, -f,
CMakeFiles/Makefile2, all], [/* 27 vars */]) = -1 ENOENT (No such file or
directory)
[pid 13615] execve(/usr/local/bin/make, [make, -f, CMakeFiles/Makefile2,
all], [/* 27 vars */]) = -1 ENOENT (No such file or directory)
[pid 13615] execve(/usr/sbin/make, [make, -f, CMakeFiles/Makefile2,
all], [/* 27 vars */]) = -1 ENOENT (No such file or directory)
[pid 13615] execve(/usr/bin/make, [make, -f, CMakeFiles/Makefile2,
all], [/* 27 vars */]) = 0
Process 13616 attached
[pid 13616] execve(/usr/local/sbin/make, [make, -f,
CMakeFiles/suxx.dir/build.make, CMakeFiles/suxx.dir/depend], [/* 27 vars
*/]) = -1 ENOENT (No such file or directory)
[pid 13616] execve(/usr/local/bin/make, [make, -f,
CMakeFiles/suxx.dir/build.make, CMakeFiles/suxx.dir/depend], [/* 27 vars
*/]) = -1 ENOENT (No such file or directory)
[pid 13616] execve(/usr/sbin/make, [make, -f,
CMakeFiles/suxx.dir/build.make, CMakeFiles/suxx.dir/depend], [/* 27 vars
*/]) = -1 ENOENT (No such file or directory)
[pid 13616] execve(/usr/bin/make, [make, -f,
CMakeFiles/suxx.dir/build.make, CMakeFiles/suxx.dir/depend], [/* 27 vars
*/]) = 0
Process 13617 attached
[pid 13617] execve(/bin/sh, [/bin/sh, -c, cd
/root/cmake_custom_libc/build  /usr/bin/cmake -E cmake_depends \Unix
Makefiles\ /root/cmake_custom_libc /root/cmake_custom_libc
/root/cmake_custom_libc/build /root/cmake_custom_libc/build
/root/cmake_custom_libc/build/CMakeFiles/suxx.dir/DependInfo.cmake --color=],
[/* 27 vars */]) = 0
Process 13618 attached
[pid 13618] 

[cmake-developers] Clarification requested on #10126 (CMake creates files with wrong permissions)

2015-08-16 Thread James Johnston
Hi,

I figured I'd take a look at resolving #10126:
http://www.cmake.org/Bug/view.php?id=10126

The fix proposed by Brad King at this ticket involves two parts.  I'd like
to seek clarification on this ticket.

1.  It is proposed to add new file permissions to INSTALL and FILE commands
called READ/WRITE/EXECUTE.

a.  So to clarify, you'd want existing OWNER_* / GROUP_* / EXECUTE_*
options to remain unmodified?  i.e. if you install(PERMISSIONS GROUP_WRITE)
this will still NOT respect the umask, correct?  (i.e. the only way to
respect the umask would be to use the NEW READ/WRITE/EXECUTE options?)

b.  If the answer to (a) is yes, what do you want to do if the user
specifies install(PERMISSIONS WRITE GROUP_WRITE)?  Is that an error?  Should
we just have the WRITE take precedence and respect the umask anyway, even
though GROUP_WRITE was specified to not respect umask?  (If the answer to
(a) is no, then obviously there's no harm in specify WRITE GROUP_WRITE
because it's purely redundant.)

c.  Would it be better to introduce a new permissions keyword for
respecting the umask for the entire set of keywords?  E.g.
install(PERMISSIONS RESPECT_UMASK GROUP_WRITE).  This could be done in
conjunction with new READ/WRITE/EXECUTE, so for example:
install(PERMISSIONS RESPECT_UMASK WRITE) would specify owner/group/world
write while respecting umask, and install(PERMISSIONS WRITE) would do the
same but NOT respect the umask.  What I like about this: (i) preserves
compatibility as if you answer yes to (a) above, (ii) avoids the issues
from (b) above.

d.  If the answer to (c) is yes, should that keyword become the default,
subject to a new policy?  (And introduction of a different NO_RESPECT_UMASK
keyword).

2.  Proposal to modify default permission copying of configure_file and
friends: I may have questions here but haven't thought it through yet.

Finally, to resolve the issue as reported by the original submitter:

Fix works almost perfectly, yet there are some files still having 0644
rights:
in builddir/CMakeFiles/ it's
- CMakeCCompiler.cmake
- CMakeCXXCompiler.cmake
- CMakeSystem.cmake

3.  Won't the proposal from #2 above fix this problem?  As in, #1 then
because a nice-to-have thing but not necessary to fix the original problem
with CMake?  (Or do we need to go on and modify the INSTALL commands in
CMake itself to use the new #1 feature above to change CMake's
installation?)

Best regards,

James Johnston


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers