Re: [CMake] Cmake/Cpack creates a corrupt .rpm
On May 30, 2019 5:21:59 PM MST, "Gonzalo Garramuño" wrote: > >El 30/5/19 a las 12:51, Gonzalo Garramuño escribió: >> rpm -ql mrViewer-v5.0.6-Linux-64.rpm > >If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm > >I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot > >make mknod: the multibyte or extended character is incomplete or >invalid, and attention: 4390 bytes of garbage skipped and header is >reversed and type of archive unknown and premature end of the archive. RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] RC compilation failing
On April 9, 2019 1:51:52 PM MDT, "Gonzalo Garramuño" wrote: >I had a resource.rc file and a resource.h file with just an ICON to >provide the icon to my application. However, since a week or so ago, >RC >refuses to compile it, giving the not very helpful message: > >Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17336 >Copyright (C) Microsoft Corporation. All rights reserved. > >RC : fatal error RW1023: I/O error seeking in file > >According to the MSDEV pages that means I don't have disk space, but >that's not true. I checked permissions too and that seemed okay too. I'm just a user of CMake. That doesn't sound like anything to do with CMake to me. I would try creating a fresh empty RC file and make sure that works. Then add the icon back. It's possible your source code control screwed up the newlines and "fixed" your icon if it thought it was a text file. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] further configuration of generated projects outside of CMake?
On March 11, 2019 6:03:24 PM MDT, hex wrote: >hi everyone, > >There are many generators supported in CMake. A CMake build system >allows me to generate the preferred build environment for everyone, >visual studio, eclipse, ninja you name it. > >The problem I see with this is that projects are generated output >files, >and even if that gives everyone the starting point in the way he/she is > >used to, they will probably want to further customize their project >preferences. But every build folder, every library that is added to the > >project sources later on in CMake must be reflected in those projects >as >well. This means any customizations done outside of CMake is lost. > You don't ship the generated files with the source. Everyone runs cmake for themselves. And if you did ship some, like a Makefile, you would not customize that any more than you'd customize it from an autoconf project. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Default CMAKE_C_FLAGS value by OS
On 02/16/2017 08:07 AM, Chuck Atkins wrote: > That being said, I do think we should revisit the use of O3 by default > given the safety issues surounding it. The following is just my opinion: In my experience if O3 fails it is a bug in the compiler, which should be fixed and somebody has to find them first. Or a bug in the code being built with O3, usually something subtle with undefined behavior. Code bugs that happen to work sort-of correctly under O2 but not O3 aren't really safe. Future compiler versions often include changes that break the code anyway. I build a couple of production release C++ projects under several versions of GCC (Linux releases since 2010). I use O3 and profiling feedback, which, yes, does reveal some bugs, even up to segfaulting the compiler, so I have special checks in the Makefile for a few of those versions. The thing that makes this safe to do is testing. If the code isn't working correctly because of O3 I know it because it fails to pass its tests. I haven't looked but I would hope CMake has tests that are run against the optimized code... -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil -- 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
Re: [CMake] Comaptibility with older gcc
On 1/27/2017 10:04 AM, Michele Portolan wrote: I have a project that build correctly using gcc 4.9.3, generating a dynamic library that I can later link to obtain my executables. So, nothing special. My problem is that on one of my target systems, I only have a gcc 4.1.2 and I am forced to use it for at least linking the last executable. My project uses extensively C++14,so I cannot build it with the older gcc. Is there a way to have Cmake generate a library that is compatible with gcc 4.1.2? I think your choices are to rewrite without C++14 or to include all of the static C++ support libraries into your library. You will need to make all your symbols hidden and then explicitly mark what you want exported. You should be doing that anyway of course. And when linking in the static libraries you will want to be sure that ld in the link step is using -exclude-libs ALL option. Because if any C++14 symbols escape from your .so it will screw up the C++03 link. Also, you won't be able to pass any complex objects or exceptions between libraries because the internal implementation of std::list and std::string has changed from 2003 to 2014. -- 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
Re: [CMake] Single Letter Omissions From File Path In Linker
On 10/14/2016 08:04 AM, Randy Turner wrote: > As you can see, the file path is missing a "t" in the first occurrence > of the word "iterator" and so that file definitely does not exist. A > file exists in the location with correct spelling, but somehow that > hardcoded path in that temporary file has dropped a letter. The specific > letter that gets dropped varies along with which file is allegedly missing. If this was all happening on the same computer I would suspect a hardware error in the RAM and I'd recommend running a night-long memory test. If this is happening on several different machines, then I don't know. It could be something that is manipulating the path name with a regular expression, or otherwise editing it. If the missing letters were immediately after a back-slash (\) then I'd suspect improper escape handling. But that doesn't seem to be it either. -- 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