Prev: Announce: Matreshka 0.0.3
Next: ANN: Units of measurement for Ada v3.0
From: Jerry on 16 Apr 2010 03:23
On Apr 15, 5:06 pm, BrianG <briang...(a)gmail.com> wrote:
> > Jerry
>
> When GNAT for DOS/Windows (yeah, a while ago - remember Ada9X?) did
> this, I used a 'wimp out' solution:
>
>     function KB_Hit return Boolean;
>     pragma Import(KB_Hit, "kbhit"); --not sure of the syntax
>     ...
>        exit when KB_Hit;
>     ...
>    (of course you have to remember to Flush or equiv)
>
> Not pretty, but it worked.
>
I would love to use this but it turns out that kbhit is a Windows
thing and possibly a Borland thing. And I'm on OS X. Seems Unix/Linux
doesn't have an equivalent which strikes me as odd. But I found an
implementation for Linux here:

http://www.pwilson.net/kbhit.html

I might give it a whirl.

Jerry

Jerry
> --BrianG
>
>         --I'm in a groove now -
>         -- Or is it a rut?

From: Jerry on 16 Apr 2010 06:25
On Apr 15, 12:22 pm, Simon Wright <si...(a)pushface.org> wrote:
> The SourceForge Leopard GNAT GPL 2009 compiler is 32-bit, while
> AdaCore's is 64-bit.
>
> I had a Leopard issue, where libtk was a thin library supporting only
> 32-bit, so I got the sort of problem you report when using AdaCore's
> compiler.
>
> Are you getting the problem with both compilers? if so, I'd expect each
> compiler to report the problem with different libraries. And your only
> recourse will be to rebuild the offending libraries with the appropriate
> compiler. What I've done is to use the matching GNAT compiler; eg for
> 64-bit,
>
> $ PATH=/opt/gnat-gpl-2009-x86_64/bin:$PATH
> $ ./configure ....
> $ make
>
> Given that most people don't build GNAT with c++, this is only going to
> work if the library concerned is C-based.
>
> You can find what architectures a library supports using lipo (-info or
> -detailed_info)

Thanks for the architecture tip. I get the problem with only the
AdaCore 64-bit compiler.

[I have another problem when using your 32-bit compiler from
Sourceforge but it's not actually a compiler problem--something goes
wrong when the PLplot build system tries to locate a compiler library:
dyld: Library not loaded: @rpath/libgnat-2009.dylib
Funny thing is, that library (or at least a symlink pointing to it) is
found earlier in the build process.]

But back to the architecture problem. ld tries to ascertain the
architecture of the output (in some cases) by looking at the
architecture of the first-listed library. In this case, that is a 32-
bit PLplot library which points to a problem in the PLplot build
process. I've sent my findings to the PLplot guys. Also, they are
attempting to link the Carbon framework in the same command which of
course is a no-no because Carbon is 32 bits.

Jerry
From: John B. Matthews on 16 Apr 2010 10:03
In article <m2zl1480t1.fsf(a)pushface.org>,
Simon Wright <simon(a)pushface.org> wrote:

> The installed .ali files should be made read-only (which may mean adding
> -f to the cp, rm calls).
>
> Not sure about the uninstall target -- shouldn't the original be
> replaced, if there was one?

You're right; thanks for commenting on this. I originally used the
target to be sure I wasn't inadvertently mixing old and new. In
practice, I use tar -zxv or svn revert to start fresh; but that seems
outside the scope of a makefile. I should at least rename the target, or
get rid of it outright.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Announce: Matreshka 0.0.3
Next: ANN: Units of measurement for Ada v3.0