Debian Sarge: problem with libgnat.so

Debian Sarge: problem with libgnat.so

[Martin Klaiber]

I've written a shared-lib in Ada with an additional C-interface some
years ago.  Included is a little programm in C to test the interface.
Since I've updated from Debian Woody to Sarge, this C-program doesn't
compile anymore (I use Gnat-3.15p now, before it was 3.14p).  Only the
C-program is affected, Ada-programs compile fine and can use the lib
without problems.

The relevant part of the Makefile is:

  INCLUDE_DIR = /usr/local/include/opensteuer
  
  .PHONY: test_c
  test_c:
          gcc -Wall -o test_c test_c.c -I$(INCLUDE_DIR) -lopensteuer -lgnat

And the error-message is:

  gcc -Wall -o test_c test_c.c -I/usr/local/include/opensteuer -lopensteuer -lgnat
  /usr/bin/ld: cannot find -lgnat
  collect2: ld returned 1 exit status

The main difference between Woody and Sarge is IMHO that the link
libgnat.so in /usr/lib is missing now.

There is a link usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat.so
pointing to /usr/lib/libgnat-3.15p.so.1.12 but it seems not to be
found.  I've added this path to /etc/ld.so.conf and to the
ADA_INCLUDE_PATH, but this makes no change.

So, I've just created this link in /usr/lib and now the compilation
works as fine as before.

What does this mean now?  Is Debian Sarge misconfigurated, or is my
system misconfigurated, or is my code in the Makefile wrong?

Thanks for your help,
Martin

Re: Debian Sarge: problem with libgnat.so

[Ludovic Brenta]

Martin Klaiber <martinkl@zedat.fu-berlin.de> writes:
>   gcc -Wall -o test_c test_c.c -I/usr/local/include/opensteuer -lopensteuer -lgnat
>   /usr/bin/ld: cannot find -lgnat
>   collect2: ld returned 1 exit status
>
> The main difference between Woody and Sarge is IMHO that the link
> libgnat.so in /usr/lib is missing now.
>
> There is a link usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat.so
> pointing to /usr/lib/libgnat-3.15p.so.1.12 but it seems not to be
> found.  I've added this path to /etc/ld.so.conf and to the
> ADA_INCLUDE_PATH, but this makes no change.
>
> So, I've just created this link in /usr/lib and now the compilation
> works as fine as before.
>
> What does this mean now?  Is Debian Sarge misconfigurated, or is my
> system misconfigurated, or is my code in the Makefile wrong?

Your Makefile is correct, except that it calls the C compiler to link
your program.  If you call gnatgcc instead, you should be fine.  By
default, gnatgcc looks in /usr/lib/gcc-lib/i486-linux/2.8.1/adalib,
but gcc (the C compiler) only looks in /usr/lib.

Adding another symlink in /usr/lib is also an option.

-- 
Ludovic Brenta (maintainer of gnat in Debian).

Re: Debian Sarge: problem with libgnat.so

[Martin Klaiber]

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:

> Your Makefile is correct, except that it calls the C compiler to link
> your program.  If you call gnatgcc instead, you should be fine.  By
> default, gnatgcc looks in /usr/lib/gcc-lib/i486-linux/2.8.1/adalib,
> but gcc (the C compiler) only looks in /usr/lib.

Hm, gnatgcc gives the same error:

  gnatgcc -Wall -o test_c test_c.c -I/usr/local/include/opensteuer -lopensteuer -lgnat
  ld: cannot find -lgnat

  martinkl [~/src/eigene/ada/opensteuer/libopensteuer] ls -l `locate libgnat.so`
  lrwxrwxrwx  1 root root 33 2005-12-22 18:55 /usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat.so -> ../../../../libgnat-3.15p.so.1.12

  martinkl [~/src/eigene/ada/opensteuer/libopensteuer] env | grep ADA
  ADA_INCLUDE_PATH=/usr/lib/ada/adalib:/usr/lib/ada/adainclude:/usr/lib/gcc-lib/i486-linux/2.8.1/adalib:/home/martinkl/lib/ada/av/1

  martinkl [~/src/eigene/ada/opensteuer/libopensteuer] cat /etc/ld.so.conf | grep /usr/lib
  /usr/lib/libc5-compat
  /usr/lib
  /usr/lib/gcc-lib/i486-linux/2.8.1/adalib

Is there anything else I need to configure?

> Adding another symlink in /usr/lib is also an option.

I want to keep it portable with other Linux-distros (if possible) as
the code is public.  Would it be better to use gnatgcc oder gcc then?

thx, Martin

Re: Debian Sarge: problem with libgnat.so

[Ludovic Brenta]

Martin Klaiber <martinkl@zedat.fu-berlin.de> writes:

> Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
>
>> Your Makefile is correct, except that it calls the C compiler to link
>> your program.  If you call gnatgcc instead, you should be fine.  By
>> default, gnatgcc looks in /usr/lib/gcc-lib/i486-linux/2.8.1/adalib,
>> but gcc (the C compiler) only looks in /usr/lib.
>
> Hm, gnatgcc gives the same error:

Oops, sorry.  I think I meant gnatmake, but even that wouldn't solve
your problem.

> I want to keep it portable with other Linux-distros (if possible) as
> the code is public.  Would it be better to use gnatgcc oder gcc then?

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)

install:
        cp -p libopensteuer.so.$(major).$(minor) /usr/local/lib
        cd /usr/local/lib; \
        ln -s libopensteuer.so.$(major).$(minor) libopensteuer.so; \
        ln -s libopensteuer.so.$(major).$(minor) libopensteuer.so.$(major)

CFLAGS := -Wall

test_c.o: test_c.c:
	gcc -c $< -o $@ $CFLAGS

test_c: test_c.o install
        gcc -o $@ $< -lopensteuer
# End of Makefile snippet

If libopensteuer is properly linked with libgnat, then it doesn't
matter what you use to do the final linking: gcc, gnatcc, gnatlink, or
even plain ld.

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.

[1] http://cert.uni-stuttgart.de/projects/ada/gnae.php

HTH

-- 
Ludovic Brenta.

Re: Debian Sarge: problem with libgnat.so

[Georg Bauhaus]

On Fri, 2005-12-23 at 13:43 +0100, Ludovic Brenta wrote:
> Martin Klaiber <martinkl@zedat.fu-berlin.de> writes:

> >> Your Makefile is correct, except that it calls the C compiler to link
> >> your program.  If you call gnatgcc instead, you should be fine.  By
> >> default, gnatgcc looks in /usr/lib/gcc-lib/i486-linux/2.8.1/adalib,
> >> but gcc (the C compiler) only looks in /usr/lib.
> >
> > Hm, gnatgcc gives the same error:
> 
> Oops, sorry.  I think I meant gnatmake, but even that wouldn't solve
> your problem.

I notice that Ubuntu doesn't have the linker problem shown, and it
comes with libgnat-3.15p-13 (Debian based)...

Re: Debian Sarge: problem with libgnat.so

[Martin Klaiber]

Ludovic Brenta <ludovic@ludovic-brenta.org> 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

Re: Debian Sarge: problem with libgnat.so

[Ludovic Brenta]

Martin Klaiber <martinkl@zedat.fu-berlin.de> writes:
[...]
>   GNAT_LIB = /usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat.so
[...]
>   .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?

Because your -L does not specify a directory name but a file name
instead.  No, your system isn't broken :)

> 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.

If you hide libgnat from C programmers, you can use gnatgcc, adagcc
(FreeBSD) or gcc or ld or whatever, and they don't have to know or
care.  They'll use just "gcc" and get libgnat pulled in by your
library.

If you make your library into a package, it will have to Build-Depend
on gnat, and Depend on libgnat-3.15p-1.

[...] About GNAE:

> 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?

The GNAE specifies that libgnat.so must be in the GNAT-specific
directory under /usr/lib/gcc-lib/.../adalib.

In Debian, most libraries intended for use from C programs come in two
packages.  Assuming a library L with soname libL.so.0, you'd have:

package libL0:
   /usr/lib/libL.so.0.1.2
   /usr/lib/libL.so.0 -> libL.so.0.1.2

package libL-dev:
   /usr/lib/libL.so -> libL.so.0.1.2

In C programs, if you specify "-lL" on your linker's command line, you
need the libL-dev package.  Your users only need the libL0 package.

Now, libgnat is not intended for use from C programs, and there is no
libgnat-dev package; instead the package gnat provides the .so link as
well as the compiler and assorted tools.  So therefore, as things
stand now, anyone who wants to specify "-lgnat" must install gnat, and
also specify -L/usr/lib/gcc-lib/.../adalib.

In the next gnat, I will provide /usr/lib/libgnat.so for the specific
purpose of making it easier to link shared libraries with libgnat.
But don't hold your breath for that next release; in any case it will
not be in Sarge but only in Etch.

-- 
Ludovic Brenta.

Re: Debian Sarge: problem with libgnat.so

[Martin Klaiber]

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:
> Martin Klaiber <martinkl@zedat.fu-berlin.de> writes:

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

> Because your -L does not specify a directory name but a file name
> instead.  No, your system isn't broken :)

Yes, thanks, this was the problem.

>> 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.

> If you hide libgnat from C programmers, you can use gnatgcc, adagcc
> (FreeBSD) or gcc or ld or whatever, and they don't have to know or
> care.  They'll use just "gcc" and get libgnat pulled in by your
> library.

I was thinking of people who want to build the library but don't have
gnatgcc.  I was trying out SuSE 8.x once, there was only gnatmake and
gcc.  I don't know if it is still like that.

Anyway, to hide libgnat from C-programmers is a good idea.  If I build
the library like you said, the linking of the C-testprogram works, but
when I want to run it, I get the following error:

  ./test_c: relocation error: /usr/local/lib/libopensteuer.so.0: undefined symbol: program_error

  ldd /usr/local/lib/libopensteuer.so
        libgnat-3.15p.so.1 => /usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat-3.15p.so.1 (0x4001a000)
        libc.so.6 => /lib/libc.so.6 (0x401bb000)
        libm.so.6 => /lib/libm.so.6 (0x402ef000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

  ldd test_c
        libopensteuer.so.0 => /usr/local/lib/libopensteuer.so.0 (0x40024000)
        libc.so.6 => /lib/libc.so.6 (0x4003d000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Is this only a problem with a wrong path?  If yes, which one is it?
LD_LIBRARY_PATH includes the adalib-directory (/usr/lib/gcc-lib/...).

> In the next gnat, I will provide /usr/lib/libgnat.so for the specific
> purpose of making it easier to link shared libraries with libgnat.

Thanks.  I think this will be a userfriendly solution if it is
permitted by the GNAE.

> But don't hold your breath for that next release; in any case it will
> not be in Sarge but only in Etch.

No problem.

As we are talking about future releases: do you know if there are
plans to include Juergen Pfeiffers AdaCurses from ncurses into one
of the next releases?  In 2003 I had some mailcontact with the
ncurses-maintainer, he kept vague in his answer.  Do you have any
interest or plan to have a adacurses-package?

I use them for a program I've written and compile them from source,
which is no problem.  But to have a package would be also nice for
people who work a lot on the console.  I've seen that Debian comes
with libtexttools, but I haven't tried it out yet.  Would it be a
better alternative?

Martin

Re: Debian Sarge: problem with libgnat.so

[Ludovic Brenta]

Martin Klaiber <martinkl@zedat.fu-berlin.de> writes:
> I was thinking of people who want to build the library but don't have
> gnatgcc.  I was trying out SuSE 8.x once, there was only gnatmake and
> gcc.  I don't know if it is still like that.

Unfortunately, I think it will be necessary to live with a
platform-specific name for the compiler driver.  Perhaps in the
future, all distributions will just use gcc, but there is no guarantee
of that.  Debian will use one of gcc or gcc-4.1 (gcc is an alias for
the default version, which may depend on the hardware architecture).

> Anyway, to hide libgnat from C-programmers is a good idea.  If I build
> the library like you said, the linking of the C-testprogram works, but
> when I want to run it, I get the following error:
>
>   ./test_c: relocation error: /usr/local/lib/libopensteuer.so.0: undefined symbol: program_error
>
>   ldd /usr/local/lib/libopensteuer.so
>         libgnat-3.15p.so.1 => /usr/lib/gcc-lib/i486-linux/2.8.1/adalib/libgnat-3.15p.so.1 (0x4001a000)
>         libc.so.6 => /lib/libc.so.6 (0x401bb000)
>         libm.so.6 => /lib/libm.so.6 (0x402ef000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>
>   ldd test_c
>         libopensteuer.so.0 => /usr/local/lib/libopensteuer.so.0 (0x40024000)
>         libc.so.6 => /lib/libc.so.6 (0x4003d000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Is this only a problem with a wrong path?  If yes, which one is it?
> LD_LIBRARY_PATH includes the adalib-directory (/usr/lib/gcc-lib/...).

It seems that the dynamic linker finds all required library.  Now,
does your C program initialise libgnat properly?  Look into "adainit"
and "adafinal" in the GNAT user's guide.

> As we are talking about future releases: do you know if there are
> plans to include Juergen Pfeiffers AdaCurses from ncurses into one
> of the next releases?  In 2003 I had some mailcontact with the
> ncurses-maintainer, he kept vague in his answer.  Do you have any
> interest or plan to have a adacurses-package?

I considered doing it, but didn't because ncurses is on all Debian
architectures whereas gnat is only on i386, sparc and powerpc.

> I use them for a program I've written and compile them from source,
> which is no problem.  But to have a package would be also nice for
> people who work a lot on the console.  I've seen that Debian comes
> with libtexttools, but I haven't tried it out yet.  Would it be a
> better alternative?

Yes, libtexttools would be a better alternative, as it provides a
thicker abstraction over the console.  You can easily do windows,
menus and support the mouse with libtexxtools.

-- 
Ludovic Brenta.