Compile libs with -fexception

[rblazek]

I know, I want probably too much. Would it be possible to compile GRASS libraries (at least core libs gis, vect, ...) with -fexception by default?

The problem is, that for example QGIS, sets error routine which throws an exception, everything works (even on Windows) but only if GRASS libs are compiled with -fexception. If -fexception flag is not used, the exception is thrown, but cannot be caught in QGIS and program is terminated.

QGIS ticket ​http://trac.osgeo.org/qgis/ticket/1878

[glynn]

Replying to rblazek:

I know, I want probably too much.

You do. Although it's not just you (see also: the vdigit module).

Would it be possible to compile GRASS libraries (at least core libs gis, vect, ...) with -fexception by default?

The GRASS libraries exist for GRASS, not QGIS.

Right now, I'm actively trying to think of ways to make life harder for anyone trying to use the GRASS libraries for anything except GRASS modules.

There are basically two types of people in the world: those who understand how much effort is saved by relying upon the OS' process mechanism for memory management and error recovery, and those who want the GRASS libraries to be usable in persistent applications.

[rblazek]

Well, I expected something like that, but I must say, that I did not expect, that you want "to make life harder for anyone trying to use the GRASS libraries". I always thought that you are just ignoring them.

I think that this ticket should be closed as wontfix, not worksforme.

Can you discover more about how you want to disable use of GRASS libraries, it could save us wasting time.

[martinl]

Replying to rblazek:

Well, I expected something like that, but I must say, that I did not expect, that you want "to make life harder for anyone trying to use the GRASS libraries". I always thought that you are just ignoring them.

I think that this ticket should be closed as wontfix, not worksforme.

Can you discover more about how you want to disable use of GRASS libraries, it could save us wasting time.

I think that ignoring people who are using GRASS libraries can be not good for GRASS project itself. This is my personal opinion.

[neteler]

Replying to glynn: ..

Right now, I'm actively trying to think of ways to make life harder for anyone trying to use the GRASS libraries for anything except GRASS modules.

I think I have to comment here:

This statement sounds a bit radical to me and don't think that it reflects the idea of collaboration across OSGeo projects.

Markus

[neteler]

Replying to rblazek:

I know, I want probably too much. Would it be possible to compile GRASS libraries (at least core libs gis, vect, ...) with -fexception by default?

I have recompiled with -fexceptions (note the s)

# using something like this:
CFLAGS="-fexceptions" ./configure ...

and did not encounter any problems in GRASS 6.4.

Radim, where do you want to see -fexceptions be used?

Markus

[glynn]

Replying to rblazek:

Well, I expected something like that, but I must say, that I did not expect, that you want "to make life harder for anyone trying to use the GRASS libraries". I always thought that you are just ignoring them.

As it appears not have been obvious, the comment wasn't entirely serious. Although it's not without some basis.

I think that this ticket should be closed as wontfix, not worksforme.

I spent some time thinking about this, and concluded that "worksforme" is correct. The libraries work for their intended purpose, i.e. GRASS modules. "wontfix" implies that there's something to fix.

Can you discover more about how you want to disable use of GRASS libraries, it could save us wasting time.

It's not that I'm actually planning to disable anything, just that making any changes which make their intended uses harder for the benefit of unintended use would occur over my dead body (well, my departure). Ditto for foregoing changes which would make intended use easier (e.g. recent changes to 7.0 mean that functions such as Rast_open_* and Rast_{get,put}_row now generate a fatal error, so callers don't have to deal with this themselves).

In that regard, -fexceptions doesn't benefit GRASS itself in any way, would require various configure checks to ensure that the compiler actually supports that flag, increases memory usage (according to the gcc docs), and may not actually help you at all (because unwinding the stack isn't going to magically revert any incomplete modifications, so there's no guarantee that the next call to a library function won't just segfault; and that's not a bug; once G_fatal_error() has been called, all bets are off).

[rblazek]

Replying to neteler:

Radim, where do you want to see -fexceptions be used?

In Lib.make? As Glynn pointed out, a test must be done if it is supported by compiler.

BUT! You don't want to see Glynn's "dead body", I believe!

[hamish]

fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:

This would be required for any C library linked by Qgis. This is out of discussion.
Qgis has to manage correctly C libraries by providing wrappers to raise execeptions
when C calls fail, else people will start asking that libc too supports
exceptions, soon or later...

[rblazek]

Replying to hamish:

fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:

 This would be required for any C library linked by Qgis. This is out of discussion.
 Qgis has to manage correctly C libraries by providing wrappers to raise execeptions
 when C calls fail, else people will start asking that libc too supports
 exceptions, soon or later...

Probably he does not know, that GRASS libraries can call exit(). No wrapper can help in that situation AFAIK.

[frankie]

Replying to rblazek:

Replying to hamish:

fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:

 This would be required for any C library linked by Qgis. This is out of discussion.
 Qgis has to manage correctly C libraries by providing wrappers to raise execeptions
 when C calls fail, else people will start asking that libc too supports
 exceptions, soon or later...

Probably he does not know, that GRASS libraries can call exit(). No wrapper can help in that situation AFAIK.

Right, libc and system calls ;-) Out of joking, those cases requires refining the library design, not dirty work arounds with limited results.

[lutra]

Replying to glynn:

Right now, I'm actively trying to think of ways to make life harder for anyone trying to use the GRASS libraries for anything except GRASS modules.

for what it's worth... -1