Re: Debian Sarge: problem with libgnat.so

Ludovic Brenta <ludovic@xxxxxxxxxxxxxxxxxx> wrote:

> I suggest that you hide libgnat from C programmers. To do this, you
> link your shared library with libgnat; unfortunately, as things stand
> now, you must use the full path for that, like so:

> # -*- Makefile -*- snippet
> adalib:=/usr/lib/gcc-lib/`gnatgcc -dumpmachine`/`gnatgcc -dumpversion`/adalib

> libopensteuer.so.$(major).$(minor): $(OBJECT_FILES)
> gnatgcc -shared -o $@ $(OBJECT_FILES) \
> -L$(adalib) -lgnat -Wl,--soname,libopensteuer.so.$(major)

Ok, I've modified my Makefile. It doesn't look exactly like yours but
should provide the same functionality. Here the relevant parts:

MAIN = libopensteuer
SOURCE = *.ad[bs] *.h
GNAT_LIB = /usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat.so

SHARED = $(MAIN).so
SHARED_API = $(SHARED).$(API)
SHARED_VERSION = $(SHARED_API).$(VERSION)

# Compile:

.PHONY: default
default:
gnatmake $(MAIN) -c -fPIC -m -O3 -largs

# Build the library:

.PHONY: shared
shared: default
gnatgcc -shared -L$(GNAT_LIB) -lgnat -Wl,-soname,$(SHARED_API) -o $(SHARED_VERSION) *.o

But this only moves the problem one step forward :-/

gnatmake libopensteuer -c -fPIC -m -O3 -largs
gnatmake: objects up to date.
gnatgcc -shared -L/usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat.so -lgnat -Wl,-soname,libopensteuer.so.0 -o libopensteuer.so.0.2004.3 *.o
ld: cannot find -lgnat

Is my system broken? Do you have an idea, why gnatgcc doesn't find
libgnat?

On the other hand, I don't want to use gnatgcc really, because there
are systems out without gnatgcc (SuSE IIRC). So, I think, I will use
the other option: ask the user if I should create /usr/lib/libgnat.so
if it is missing.

> As to portability, the only standard layout for Ada files is the GNU
> Ada Environment Specification[1]. It might be worthwhile to see if we
> can improve this standard. Also, the only GNU/Linux distribution I
> know of that conforms to this standard is Debian.

Indeed. But the paper doesn't mention a situation as we might have in
my case: somebody installs the libraries needed for this program (for
instance by a package-manager which only does the default installation,
i.e. no extra creation of links).

But this person does not install the Ada-compiler, as he only wants to
build a C-program using my library. So he would only have $(CC), and
as you said, C-compilers would look in /usr/lib vor libgnat.so, not in
/usr/lib/gcc-lib/...

Doesn't this mean that we always should have /usr/lib/libgnat.so?

Or, to ask the other way round: is there a special reason why we don't
have this link in /usr/lib?

Martin
.

Relevant Pages

  • Re: Debian Sarge: problem with libgnat.so
    ... If you hide libgnat from C programmers, you can use gnatgcc, adagcc ... If you make your library into a package, ... > But this person does not install the Ada-compiler, ... most libraries intended for use from C programs come in two ...
    (comp.lang.ada)
  • Re: Debian Sarge: problem with libgnat.so
    ... why gnatgcc doesn't find ... > If you hide libgnat from C programmers, you can use gnatgcc, adagcc ... They'll use just "gcc" and get libgnat pulled in by your ... > purpose of making it easier to link shared libraries with libgnat. ...
    (comp.lang.ada)
  • Re: Writing bulletproof code
    ... Good software design requires that you put error ... > the 'C' language and the libraries. ... It doesn't actually solve the problem that programmers are ... very few know when the cost will be negligible ...
    (comp.programming)
  • Re: Critique on my solution for an exercise. (check if a date is valid)
    ... One thing that strikes me as I read Bernd's conversation with Aleksej ... arguments against grotesque caricatures of programmers. ... generalized solutions and libraries, ... we had two primary constraints. ...
    (comp.lang.forth)
  • Re: <ctype.h> toLower()
    ... I konow several real world programmers, ... >> And portability is in most cases a very low priority as in most cases ... > the past 10 years I only wrote some specific platform specific software. ... > libraries did their job well). ...
    (alt.comp.lang.learn.c-cpp)