Re: [CMake] Cmake/Cpack creates a corrupt .rpm

2019-05-30 Thread Zan Lynx
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

2019-04-09 Thread Zan Lynx
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?

2019-03-11 Thread Zan Lynx
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

2017-02-16 Thread Zan Lynx
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

2017-01-27 Thread Zan Lynx

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

2016-10-14 Thread Zan Lynx
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