Prev: InformationWeek Gives Ada Black Eye
Next: Error when running gcc from GPS
From: Warren on 26 Apr 2010 11:01
Stephen Leake expounded in news:82fx2lm74h.fsf(a)stephe-leake.org:

> Warren <ve3wwg(a)gmail.com> writes:
>
>> Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
>> @k36g2000yqn.googlegroups.com:
>>
>>> On Apr 23, 5:44 pm, Warren <ve3...(a)gmail.com> wrote:
>>>>
>>>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>>>> and PostgreSQL etc., it is unavoidable. :)  I tried to avoid C++
>>>> like the plague, but ncurses requires a C++ main, if GNAT exceptions
>>>> are to work correctly. I'm not sure of the details why, but a GNAT
>>>> exception + ncurses and a C or gnat main leads to an abort.
>>>> Switching to a C++ main program has corrected that.
>>>>
>>> Did you try to pass -shared to gnatbind?
>>
>> No, but is that really relevant?
>>
>> The problem was not library linkage, but the fact that
>> if an exception was raised in the Ada modules, the
>> exception handler would not work -- the whole unit
>> would abort.
>
> Lots of things are relevant in exception handling.
>
> First is the exception handling mechanism; set-jump/long-jump vs zero
> cost. GNAT supports both, with zero cost the default; Windows dlls
> require sj/lj.
>
> It may be that using a C++ main also implies the sj/lj mechanism.

Ok, but how is that connected with "-shared"?

Warren
From: Charmed Snark on 26 Apr 2010 11:06
Ludovic Brenta expounded in news:871ve53e1h.fsf(a)ludovic-brenta.org:

> Warren <ve3wwg(a)gmail.com> writes:
>> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
>> 4958c6bdff4f(a)q15g2000yqj.googlegroups.com:
>>> On Apr 21, 11:54pm, Warren <ve3...(a)gmail.com> wrote:
>>>> Has anyone here had experience using GNAT with autoconf/automake?
...
> On the contrary; in most of my Debian packages, I bypass the brittle
> autocrap, evil recursive makefiles (that do not play well with the
...
> I can do that because I do not care about portability to platforms
other
> than Debian

But one platform vastly simplifies things ;-)

>> This becomes especially crucial when you try to make the project build
>> under HPUX, Solaris, AIX and OSX in addition to usual Linux/*BSD
>> lineup. The environments are different enough to frustrate any simple
>> minded configuration management system.
>
> That's correct but assumes you want to take the burden of doing all
this
> by yourself.

But that is precisely what the autocrap is for. It does work,
albeit a bit unweildy. I resisted it myself for years, but once
you embrace the darkside, you do find that it can work, when
sufficiently coaxed.

Warren
From: Warren on 26 Apr 2010 11:25
Vadim Godunko expounded in news:ddd15bde-3294-416e-916c-
64c6c686b31f(a)b33g2000yqc.googlegroups.com:

> By the way, configure equivalent, written in Ada, included in
> Matreshka, it is still relatively simple, but good enough to detect
> several important properties of target system like size of the
> address, endianess, support of atomic operations by architecture and
> support for MMX/SSE by Ada compiler.

But I need more than that. There are platform issues with NaN, infinity
constants and their handling. Also many differences in curses.

Solaris adds grief for C types of attributes and the lack of/difference
in certain attribute functions. I also need to know whether you can
customize the colour palette in a given implementation of curses (and
pdcurses). Include files vary by platform for some of the C routines,
which will be called by the Ada code. Whether or not I have alloca()
support is another important configuration item.

Add to that release to release changes in 3rd party support like libgsl,
libgmp and PostgreSQL and you'll find a strong need for extensive
configuration control. So autocrap does control all that for me, along
with a few hand-crafted platform tests where it falls short.

Warren
From: Robert A Duff on 26 Apr 2010 14:30
Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes:

> Warren <ve3wwg(a)gmail.com> writes:
>
>> Vadim Godunko expounded in news:d50d540f-8fdf-40ae-9301-
>> 4958c6bdff4f(a)q15g2000yqj.googlegroups.com:
>>
>>> On Apr 21, 11:54pm, Warren <ve3...(a)gmail.com> wrote:
>>>> Has anyone here had experience using GNAT with autoconf/automake?

I have. It's a nightmare, as others have said.

If you absolutely must use these tools, I suggest you
minimize their use. Most of what you need can be
done using gprbuild, which can be called from
a make file (preferably hand written, not generated
via 37 levels of confusing tools).

> >> I used them long time ago. I don't known any project which still use
> >> them now, but them was used in old versions of PolyORB and QtAda.

PolyORB still uses autoconf, but I got rid of automake, which
was a big improvement.

> On the contrary; in most of my Debian packages, I bypass the brittle
> autocrap, evil recursive makefiles...

Here's a paper, "Recursive Make Considered Harmful":

http://miller.emu.id.au/pmiller/books/rmch/

which explains why recursive makefiles are evil,
and how to do it right. (Of course, most of what
make does is done better by gprbuild -- but not
everything.)

>... (that do not play well with the
> parallel build support in gnatmake)...

Not just that. Recursive make files don't even work well
with make -- they are grossly inefficient. Even more so
under cygwin.

>...and unmaintainable libtool mess in
> favour of a single, simple, hand-written makefile and one GNAT project
> file. This works MUCH better in my experience.

- Bob
From: Alex R. Mosteo on 27 Apr 2010 02:57
Warren wrote:

> Stephen Leake expounded in news:82fx2lm74h.fsf(a)stephe-leake.org:
>
>> Warren <ve3wwg(a)gmail.com> writes:
>>
>>> Vadim Godunko expounded in news:5867de55-7ca2-4c64-a72f-d2343153eef0
>>> @k36g2000yqn.googlegroups.com:
>>>
>>>> On Apr 23, 5:44 pm, Warren <ve3...(a)gmail.com> wrote:
>>>>>
>>>>> For a basic interpreter, making use of ncurses, libgmp, libgsl,
>>>>> and PostgreSQL etc., it is unavoidable. :) I tried to avoid C++
>>>>> like the plague, but ncurses requires a C++ main, if GNAT exceptions
>>>>> are to work correctly. I'm not sure of the details why, but a GNAT
>>>>> exception + ncurses and a C or gnat main leads to an abort.
>>>>> Switching to a C++ main program has corrected that.
>>>>>
>>>> Did you try to pass -shared to gnatbind?
>>>
>>> No, but is that really relevant?
>>>
>>> The problem was not library linkage, but the fact that
>>> if an exception was raised in the Ada modules, the
>>> exception handler would not work -- the whole unit
>>> would abort.
>>
>> Lots of things are relevant in exception handling.
>>
>> First is the exception handling mechanism; set-jump/long-jump vs zero
>> cost. GNAT supports both, with zero cost the default; Windows dlls
>> require sj/lj.
>>
>> It may be that using a C++ main also implies the sj/lj mechanism.
>
> Ok, but how is that connected with "-shared"?

Stab in the dark here; I've read in the past when looking for fully
statically linked programs that shared runtimes are/were needed for c++
exception mechanisms to work; or at least to keep all corner cases covered.

So I wouldn't be surprised if -shared did indeed affect some exception
related stuff.

What I read was something similar to this, but it was a long time ago:

http://www.trilithium.com/johan/2005/06/static-libstdc/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: InformationWeek Gives Ada Black Eye
Next: Error when running gcc from GPS