Version 2.8 affects exception handling?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Version 2.8 affects exception handling?

Bill Spotz
Hi,

I am a Trilinos developer, so I recently upgraded to CMake version 2.8  
so that I could test the Trilinos release 10 tarball.

I am seeing certain unit tests fail that were working before (in the  
Trilinos release 10 repository) and this is the current state of my  
debugging process:

   * I am testing that a constructor given an invalid (negative)  
argument throws an exception
   * gdb indicates that the exception is thrown, but I cannot catch it
   * the program crashes with a segmentation fault

I don't see any changes by other developers that would change the  
behavior of the code I am testing.  The only difference I am aware of  
between the code that was working and the code that is failing now is  
the CMake version used to build it.

Might CMake be compiling with options that affect exception handling?  
If so, how can I determine what it is doing and customize it to behave  
the way I expect it to?

Thanks,

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-0154      **
** Albuquerque, NM 87185-0370    Email: [hidden email] **






_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Bill Hoffman
Bill Spotz wrote:

> Hi,
>
> I am a Trilinos developer, so I recently upgraded to CMake version 2.8
> so that I could test the Trilinos release 10 tarball.
>
> I am seeing certain unit tests fail that were working before (in the
> Trilinos release 10 repository) and this is the current state of my
> debugging process:
>
>   * I am testing that a constructor given an invalid (negative) argument
> throws an exception
>   * gdb indicates that the exception is thrown, but I cannot catch it
>   * the program crashes with a segmentation fault
>
> I don't see any changes by other developers that would change the
> behavior of the code I am testing.  The only difference I am aware of
> between the code that was working and the code that is failing now is
> the CMake version used to build it.
>
> Might CMake be compiling with options that affect exception handling?  
> If so, how can I determine what it is doing and customize it to behave
> the way I expect it to?
>
Not that I know of...

If you have a build that works and one that does not, perhaps you could
do a make VERBOSE=1, and post the build for a .o and the linking of an
executable for the version that works and the one that does not and we
can compare flags to figure out what is going on.

-Bill

_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Bill Spotz
On Oct 21, 2009, at 7:44 AM, Bill Hoffman wrote:

> Bill Spotz wrote:
>> Hi,
>>
>> I am a Trilinos developer, so I recently upgraded to CMake version  
>> 2.8
>> so that I could test the Trilinos release 10 tarball.
>>
>> I am seeing certain unit tests fail that were working before (in the
>> Trilinos release 10 repository) and this is the current state of my
>> debugging process:
>>
>>  * I am testing that a constructor given an invalid (negative)  
>> argument
>> throws an exception
>>  * gdb indicates that the exception is thrown, but I cannot catch it
>>  * the program crashes with a segmentation fault
>>
>> I don't see any changes by other developers that would change the
>> behavior of the code I am testing.  The only difference I am aware of
>> between the code that was working and the code that is failing now is
>> the CMake version used to build it.
>>
>> Might CMake be compiling with options that affect exception handling?
>> If so, how can I determine what it is doing and customize it to  
>> behave
>> the way I expect it to?
>>
> Not that I know of...
>
> If you have a build that works and one that does not, perhaps you  
> could
> do a make VERBOSE=1, and post the build for a .o and the linking of an
> executable for the version that works and the one that does not and we
> can compare flags to figure out what is going on.

I finally got around to doing this, and the only difference in the  
compile flags is that the new version of cmake uses the compiler flag

     -mmacosx-version-min=10.5

where the old one does not.  My MACOSX_DEPLOYMENT_TARGET environment  
variable is set to 10.5 either way, so I'm not even sure this would  
make a difference.

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-0154      **
** Albuquerque, NM 87185-0370    Email: [hidden email] **


_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Bill Hoffman
Bill Spotz wrote:

> I finally got around to doing this, and the only difference in the
> compile flags is that the new version of cmake uses the compiler flag
>
>     -mmacosx-version-min=10.5
>
> where the old one does not.  My MACOSX_DEPLOYMENT_TARGET environment
> variable is set to 10.5 either way, so I'm not even sure this would make
> a difference.
>

This is from these two bugs:

http://public.kitware.com/Bug/view.php?id=9959
http://public.kitware.com/Bug/view.php?id=6195

If the user does not specify a deployment target, CMake should not use
one.  As a rule we try to keep CMake as default as possible.   gcc -o
foo foo.c should be the same as add_executable(foo foo.c).  In this case
that is not true...   Will come up with a fix for 2.8.1.   As a work
around, I think if you do this set(CMAKE_OSX_DEPLOYMENT_TARGET "") it
should stop CMake from adding the flag.

-Bill
_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Bill Spotz
On Nov 28, 2009, at 11:40 AM, Bill Hoffman wrote:

> Bill Spotz wrote:
>
>> I finally got around to doing this, and the only difference in the
>> compile flags is that the new version of cmake uses the compiler flag
>>
>>    -mmacosx-version-min=10.5
>>
>> where the old one does not.  My MACOSX_DEPLOYMENT_TARGET environment
>> variable is set to 10.5 either way, so I'm not even sure this would  
>> make
>> a difference.
>>
>
> This is from these two bugs:
>
> http://public.kitware.com/Bug/view.php?id=9959
> http://public.kitware.com/Bug/view.php?id=6195
>
> If the user does not specify a deployment target, CMake should not use
> one.  As a rule we try to keep CMake as default as possible.   gcc -o
> foo foo.c should be the same as add_executable(foo foo.c).  In this  
> case
> that is not true...   Will come up with a fix for 2.8.1.   As a work
> around, I think if you do this set(CMAKE_OSX_DEPLOYMENT_TARGET "") it
> should stop CMake from adding the flag.


So set(CMAKE_OSX_DEPLOYMENT_TARGET "") doesn't seem to work: I am  
still getting the -mmacosx-version-min=10.5 compiler options.  I'm  
still not sure why this would cause the problems I am seeing, which  
are exceptions not getting caught.

I have constructed a smaller build, which makes it easier to find all  
of the differences.  I have also found linker options

     -L/sw/lib/gcc4.4/lib/gcc/i686-apple-darwin9/4.4.1
     -L/sw/lib/gcc4.4/lib
     -lgfortranbegin
     -lgfortran

when the epetra dynamic library gets linked under the new cmake and  
not the old.  This could be problematic because it is using the  
compiler /usr/bin/c++, which on my system is version 4.0.1 (although  
the gfortran compiler is version 4.4.1).

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-0154      **
** Albuquerque, NM 87185-0370    Email: [hidden email] **


_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Bill Spotz
> On Nov 28, 2009, at 11:40 AM, Bill Hoffman wrote:
>
>> This is from these two bugs:
>>
>> http://public.kitware.com/Bug/view.php?id=9959
>> http://public.kitware.com/Bug/view.php?id=6195
>>
>> If the user does not specify a deployment target, CMake should not  
>> use
>> one.  As a rule we try to keep CMake as default as possible.   gcc -o
>> foo foo.c should be the same as add_executable(foo foo.c).  In this
>> case
>> that is not true...   Will come up with a fix for 2.8.1.   As a work
>> around, I think if you do this set(CMAKE_OSX_DEPLOYMENT_TARGET "") it
>> should stop CMake from adding the flag.
>
>
> So set(CMAKE_OSX_DEPLOYMENT_TARGET "") doesn't seem to work: I am
> still getting the -mmacosx-version-min=10.5 compiler options.  I'm
> still not sure why this would cause the problems I am seeing, which
> are exceptions not getting caught.
>
> I have constructed a smaller build, which makes it easier to find all
> of the differences.  I have also found linker options
>
>     -L/sw/lib/gcc4.4/lib/gcc/i686-apple-darwin9/4.4.1
>     -L/sw/lib/gcc4.4/lib
>     -lgfortranbegin
>     -lgfortran
>
> when the epetra dynamic library gets linked under the new cmake and
> not the old.  This could be problematic because it is using the
> compiler /usr/bin/c++, which on my system is version 4.0.1 (although
> the gfortran compiler is version 4.4.1).


So I have been able to confirm that it is these fortran-related link  
options that are causing my problem.  I'm not exactly sure what to  
make of the fact that it links and runs properly without them, but  
links and runs improperly with them.

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-0154      **
** Albuquerque, NM 87185-0370    Email: [hidden email] **






_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Bill Hoffman
Bill Spotz wrote:

>>
>> when the epetra dynamic library gets linked under the new cmake and
>> not the old.  This could be problematic because it is using the
>> compiler /usr/bin/c++, which on my system is version 4.0.1 (although
>> the gfortran compiler is version 4.4.1).
>
>
> So I have been able to confirm that it is these fortran-related link
> options that are causing my problem.  I'm not exactly sure what to make
> of the fact that it links and runs properly without them, but links and
> runs improperly with them.
>

I think we sort of decided that mixing versions of gcc tools does work
reliably.   There is a way to update your Mac to have matching c++ and
fortran.  Not sure how it worked before, but CMake is doing the "right"
thing by linking in the fortran library you are actually using.  Not
sure why it was working before...

-Bill
_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Version 2.8 affects exception handling?

Brad King
Bill Hoffman wrote:

> Bill Spotz wrote:
>>> when the epetra dynamic library gets linked under the new cmake and
>>> not the old.  This could be problematic because it is using the
>>> compiler /usr/bin/c++, which on my system is version 4.0.1 (although
>>> the gfortran compiler is version 4.4.1).
>>
>> So I have been able to confirm that it is these fortran-related link
>> options that are causing my problem.  I'm not exactly sure what to
>> make of the fact that it links and runs properly without them, but
>> links and runs improperly with them.
>
> I think we sort of decided that mixing versions of gcc tools does work
> reliably.

Bill H. meant "mixing versions of gcc tools does NOT work reliably".

The flags

    -L/sw/lib/gcc4.4/lib/gcc/i686-apple-darwin9/4.4.1
    -L/sw/lib/gcc4.4/lib
    -lgfortranbegin
    -lgfortran

have been detected as something gfortran implicitly uses to link.
Since the project contains both C++ and Fortran code, it uses the
C++ linker and passes the implicit Fortran flags explicitly.  The
problem with mixed versions is that the .../4.4.1 path probably
contains its own libstdc++, so when the C++ compiler from 4.0.1
implicitly links to that library it finds the wrong version because
the explicit search path comes first.

-Brad
_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake