Quantcast

CMAKE_SIZEOF_VOID_P question

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CMAKE_SIZEOF_VOID_P question

thoni56
I'm developing a library on and for a multitude of platforms and would
like to provide both 32 and 64-bit versions for all platforms this is
relevant for.

I'm currently on Ubuntu 64bit with CMake 3.5.2 and use the "-m32"
compiler switch to do the 32-bit compile.

I'm trying to understand why GNUInstallDirs are not setting
CMAKE_INSTALL_LIBDIR to what I think it should. While doing that I
discovered that CMAKE_SIZEOF_VOID_P is not set as I thought it would
either.

According to the documentation CMAKE_SIZEOF_VOID_P it is determined by
running the compiler. However it seems that it is not using pertinent
flags from the configuration, in particular CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS.

Having a CMakeLists.txt containing:

> cmake_minimum_required(VERSION 2.8.5)
> project(X C)
> try_run(run_result_var compile_result_var /tmp /tmp/size.c)
> message(STATUS "Sizeof=" ${run_result_var})
> message(STATUS "CMAKE_SIZEOF_VOID_P=" ${CMAKE_SIZEOF_VOID_P})

and size.c with:

> int main(int argc, char **argv) {
>     return sizeof(void *);
> }

With no flags I get:

> -- Sizeof=8
> -- CMAKE_SIZEOF_VOID_P=8

And with CMAKE_C_FLAGS set to "-m32" I get:

> -- Sizeof=4
> -- CMAKE_SIZEOF_VOID_P=8

If this is by design, then I think the documentation is unclear, if not
plain wrong:

> This is set to the size of a pointer on the target machine, and is
> determined by a try compile.
> If a 64-bit size is found, then the library search path is modified
> to look for 64-bit libraries first.

Or am I missing something?

/Thomas

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMAKE_SIZEOF_VOID_P question

Chuck Atkins
Hi Thomas,

According to the documentation CMAKE_SIZEOF_VOID_P it is determined by running the compiler. However it seems that it is not using pertinent flags from the configuration, in particular CMAKE_C_FLAGS and CMAKE_CXX_FLAGS.

It is but the results from type size checking get saved in cache variables so when run a second time, even though specifying extra CMAKE_CXX_FLAGS, the CMAKE_SIZEOF_VOID_P variable already exists in cache so it's not checked again.  If you clear your build directory before each invocation of CMake then you should see it switch between 4 and 8 as expected.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
 


--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMAKE_SIZEOF_VOID_P question

thoni56



Den 2017-04-14 kl. 21:27, skrev Chuck Atkins:
Hi Thomas,

According to the documentation CMAKE_SIZEOF_VOID_P it is determined by running the compiler. However it seems that it is not using pertinent flags from the configuration, in particular CMAKE_C_FLAGS and CMAKE_CXX_FLAGS.

It is but the results from type size checking get saved in cache variables so when run a second time, even though specifying extra CMAKE_CXX_FLAGS, the CMAKE_SIZEOF_VOID_P variable already exists in cache so it's not checked again.  If you clear your build directory before each invocation of CMake then you should see it switch between 4 and 8 as expected.


Right, it does. Thanks. The inconsistencies of when something changes and when it doesn't, bit me again...

Next question is then why doesn't GNUInstallDirs set CMAKE_INSTALL_LIBDIR as I expect on Ubuntu for the example I gave?

I am expecting to see either lib64/lib (for 64/32 bit) or a triplet for (32-bit). Now it's always 'lib'.

/Thomas

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
 



--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMAKE_SIZEOF_VOID_P question

Ghislain Vaillant
In reply to this post by thoni56
> Next question is then why doesn't GNUInstallDirs set
> CMAKE_INSTALL_LIBDIR as I expect on Ubuntu for the example I gave?
>
> I am expecting to see either lib64/lib (for 64/32 bit) or a triplet for
> (32-bit). Now it's always 'lib'.

Debian / Ubuntu injects this additional triplet for multiarch support
[1]. As far as you are concerned, you can safely ignore this detail.

[1] https://wiki.debian.org/Multiarch

Ghis
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMAKE_SIZEOF_VOID_P question

thoni56

Ghislain Vaillant skrev:

>> Next question is then why doesn't GNUInstallDirs set
>> CMAKE_INSTALL_LIBDIR as I expect on Ubuntu for the example I gave?
>>
>> I am expecting to see either lib64/lib (for 64/32 bit) or a triplet for
>> (32-bit). Now it's always 'lib'.
>
> Debian / Ubuntu injects this additional triplet for multiarch support
> [1]. As far as you are concerned, you can safely ignore this detail.
>
> [1] https://wiki.debian.org/Multiarch
>
> Ghis
I'm not sure I understand what you mean by "ignore" or exactly what I
should ignore. All I want is that CMake installs libraries in a place
that the linker will find them depending on the target architecture.
With "target architecture" I mean either a 32-bit compile and link or a
64-bit compile and link. For all 64bit unixen that I know, you can also
compile for 32bit architectures (with GCC-compatible compilers) and run
them on the same OS.

Do you mean I should ignore the whole "where goes my library" issue, or
just fact that the triplet may or may not be used?

To enable a 32bit compiled application to find the 32bit version of my
library it should install in a place where the linker looks for those:

> gcc -m32 -Xlinker --verbose  2>/dev/null | grep SEARCH | sed
> 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g'  | grep -vE '^$'
> /usr/i386-linux-gnu/lib32
> /usr/x86_64-linux-gnu/lib32
> /usr/local/lib/i386-linux-gnu
> /usr/local/lib32
> /lib/i386-linux-gnu
> /lib32
> /usr/lib/i386-linux-gnu
> /usr/lib32
> /usr/local/lib
> /lib
> /usr/lib
and dito for a 64bit version:

> gcc -m64 -Xlinker --verbose  2>/dev/null | grep SEARCH | sed
> 's/SEARCH_DIR("=\?\([^"]\+\)"); */\1\n/g'  | grep -vE '^$'
> /usr/x86_64-linux-gnu/lib64
> /usr/local/lib/x86_64-linux-gnu
> /usr/local/lib64
> /lib/x86_64-linux-gnu
> /lib64
> /usr/lib/x86_64-linux-gnu
> /usr/lib64
> /usr/local/lib
> /lib
> /usr/lib
As we can see the triplets are there, for sure.

And since I want the two versions to exist side-by-side on the same
system, I was hoping that GNUInstallDirs did something intelligent with
its knowledge of the CMAKE_SIZEOF_VOID_P. And it turns out it does on
some systems. E.g on WSL with Ubuntu 14.04 and a native (64-bit) compile
CMAKE_INSTALL_LIBDIR is set to  "lib/x86_64-linux-gnu" and with "-m32"
(32bit) it is set to "lib". But on Ubuntu 16.10 it seems to generate
"lib" for both cases.

Is this a bug with GNUInstallDirs?

/Thomas

--

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
Loading...