* Debian Sarge: problem with libgnat.so @ 2005-12-22 21:12 Martin Klaiber 2005-12-22 23:35 ` Ludovic Brenta 0 siblings, 1 reply; 9+ messages in thread From: Martin Klaiber @ 2005-12-22 21:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-22 21:12 Debian Sarge: problem with libgnat.so Martin Klaiber @ 2005-12-22 23:35 ` Ludovic Brenta 2005-12-23 0:15 ` Martin Klaiber 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Brenta @ 2005-12-22 23:35 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-22 23:35 ` Ludovic Brenta @ 2005-12-23 0:15 ` Martin Klaiber 2005-12-23 12:43 ` Ludovic Brenta 0 siblings, 1 reply; 9+ messages in thread From: Martin Klaiber @ 2005-12-23 0:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-23 0:15 ` Martin Klaiber @ 2005-12-23 12:43 ` Ludovic Brenta 2005-12-23 16:10 ` Georg Bauhaus 2005-12-23 23:35 ` Martin Klaiber 0 siblings, 2 replies; 9+ messages in thread From: Ludovic Brenta @ 2005-12-23 12:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-23 12:43 ` Ludovic Brenta @ 2005-12-23 16:10 ` Georg Bauhaus 2005-12-23 23:35 ` Martin Klaiber 1 sibling, 0 replies; 9+ messages in thread From: Georg Bauhaus @ 2005-12-23 16:10 UTC (permalink / raw) 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)... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-23 12:43 ` Ludovic Brenta 2005-12-23 16:10 ` Georg Bauhaus @ 2005-12-23 23:35 ` Martin Klaiber 2005-12-24 0:23 ` Ludovic Brenta 1 sibling, 1 reply; 9+ messages in thread From: Martin Klaiber @ 2005-12-23 23:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-23 23:35 ` Martin Klaiber @ 2005-12-24 0:23 ` Ludovic Brenta 2005-12-27 12:23 ` Martin Klaiber 0 siblings, 1 reply; 9+ messages in thread From: Ludovic Brenta @ 2005-12-24 0:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-24 0:23 ` Ludovic Brenta @ 2005-12-27 12:23 ` Martin Klaiber 2005-12-27 15:43 ` Ludovic Brenta 0 siblings, 1 reply; 9+ messages in thread From: Martin Klaiber @ 2005-12-27 12:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Debian Sarge: problem with libgnat.so 2005-12-27 12:23 ` Martin Klaiber @ 2005-12-27 15:43 ` Ludovic Brenta 0 siblings, 0 replies; 9+ messages in thread From: Ludovic Brenta @ 2005-12-27 15:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-12-27 15:43 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-12-22 21:12 Debian Sarge: problem with libgnat.so Martin Klaiber 2005-12-22 23:35 ` Ludovic Brenta 2005-12-23 0:15 ` Martin Klaiber 2005-12-23 12:43 ` Ludovic Brenta 2005-12-23 16:10 ` Georg Bauhaus 2005-12-23 23:35 ` Martin Klaiber 2005-12-24 0:23 ` Ludovic Brenta 2005-12-27 12:23 ` Martin Klaiber 2005-12-27 15:43 ` Ludovic Brenta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox