Menu
▾
▴
#6 LD_LIBRARY_PATH breaks RPMbuild.
In Fedora 5, after building and installing
gnat-gpl-2006-r5, I can't build any more Gnat GPL
packages, because RPMbuild doesn't work after the
Package scripts run "Set_GNAT gpl".
The error message is "rpmbuild:
/opt/gnat/gpl/lib/libgcc_s.so.1: version `GCC_4.2.0'
not found (required by /usr/lib/libstdc++.so.6)". This
happens when the value of LD_LIBRARY_PATH is
"/opt/gnat/gpl/lib::/opt/gnat/gpl/lib/gnat/asis/lib".
When I reset it to an empty value (which it normally is
in Fedora 5), then RPMbuild works again. Apparently
LD_LIBRARY_PATH makes the dynamic linker look in
/opt/gnat/gpl/lib instead of /lib for libraries that
RPMbuild needs. It seems that changing LD_LIBRARY_PATH
like this isn't a very good idea. What was the
rationale for changing it?
Logged In: YES
user_id=697486
Hello Björn
The main reason for changing LD_LIBRARY_PATH is Gtk. I don't
know about FC but the Gtk which comes with SuSE is to old
for GtkAda 2.8.1 and GtkAda 2.8.1 is to old for GPS 4.0.0 -
which I still hope to provide one day.
According to doc LD_LIBRARY_PATH should complement but not
replace /etc/ld.so.conf.
Besides: GCC_4.2.0?? - currently released is 4.1.1 and even
AdaCore is only beta testing against 4.1.2.
Martin
Logged In: YES
user_id=1037163
I guess the linker stops at the first library it finds that
seems to match, and it looks in the directories listed in
LD_LIBRARY_PATH before those in /etc/ld.so.conf.
As LD_LIBRARY_PATH is effective at run time, I suppose
you'll have to run Set_GNAT not only when compiling but also
when using the compiled programs. I'd suggest that you
explore LD_RUN_PATH and the -rpath option of LD. I have no
experience with those, but they're supposed to set a library
search path that gets compiled into the binary and will be
searched at run time.
Let's see, I have packages named gtk+-1.2.10-50 and
gtk2-2.8.20-1 installed. The latter is an update released
yesterday. There have been updates with 2.8.19 and 2.8.18
before, but at the original Fedora Core 5 release it was
2.8.15. The README for GtkAda says it's been tested with
Gtk+ 2.8.17. I don't think I'll have to build an alternate
GTK. I just hope 2.8.20 isn't too new.
Yes, it's strange that it says "GCC_4.2.0". I don't know
what that means. It doesn't seem to be the version of
libgcc_s itself, as the ordinary version has the full name
/lib/libgcc_s-4.1.1-20060525.so.1, and that's obviously OK
for RPMbuild.
Logged In: YES
user_id=697486
LD_RUN_PATH and -rpath:
tried that - but it does not allways work. Somehow I feel
that LD_RUN_PATH is completely ingnored and not all ./
configure scripts propperly support LIBS where one would
need to add -rpath (-R which does the same if the parameter
is a directory).
but I have another try.
Martin
Logged In: YES
user_id=697486
I remove the references LD_LIBRARY_PATH - would you all
have a look to see if it works. Of corse we only know once
we have a Gtk/Ada application up an running.
Martin
Logged In: YES
user_id=1037163
A preliminary report: Using the latest configure scripts I
got the following error when compiling GTKada with Gnat/GPL,
but not with Gnat/GCC:
gcc -c -O2 -gnatn -gnatws gate.adb
gnatbind -x gate.ali
fatal error: file gtk-glade.ali is incorrectly formatted
make sure you are using consistent versions of gcc/gnatbind
This could mean that some component of the system GCC was
called instead of the one from Gnat/GPL, or it could be that
I did something wrong. I'll continue testing later.
Logged In: YES
user_id=697486
Hi,
I hope you noticed all the little helpers like
"Package_Step_2.bash" and "Install_Step_1.bash". Even if you
do not use them it's allways worth a look. The correct order
of execution is:
Package_Gtk.bash
Package_Step_1.bash
Install_Step_1.bash
Package_Step_2.bash
Install_Step_2.bash
Package_Step_3.bash
Install_Step_3.bash
"The README for GtkAda says it's been tested with Gtk+ 2.8.17"
I read that as well and I fear it is old news which was not
updated.
"I just hope 2.8.20 isn't too new."
I tried various 2.8., 2.9. version - with no luck. Only
the version in
http://sourceforge.net/project/showfiles.php?group_id=12974&package_id=191849
worked well. For Gtk/Ada 2.8.0 the Gtk fron SuSE was fine.
Martin
Logged In: YES
user_id=1037163
OK, I finally got everything built and installed. (The error
I mentioned about an incorrectly formatted ALI file was
because of an old code tree in the BUILD directory.) To test
GTKada I compiled and ran the program "anim" in GTKada's
examples/doublebuffer, and ran "lsof -p" on it. Other than
/opt/gnat/gpl/lib/gtkada/libgtkada-2.8.so.1, all the
libraries it had loaded were from /usr/lib. Then I added
/opt/gnat/tools/lib to LD_RUN_PATH and compiled anim again,
and this time it loaded GTK, GDK, Pango, Cairo and others
from /opt/gnat/tools/lib. So LD_RUN_PATH wasn't ignored but
it needs some more tweaking.
How do you determine which versions of GTK work with GTKada?
It appears to build fine with GTK 2.8.20 for me. I've had
some compilation errors but they all turned out to be either
mismatched gnat-g?? and gnat-g??-devel packages, or that one
Gnat tried to work with ALI files written by another Gnat.
I've packaged GTK 2.10.0 now, but I'd still like to know how
you know that a certain version is too old.
I do use the Package* scripts, but so far I've always
invoked RPM directly to install the packages.
Logged In: YES
user_id=697486
"How do you determine which versions of GTK work with
GtKada?"
Try and Error. I donwnloaded half a dozend of them and
tryed them one after the other - starting with the one
suggesed in the README and then using newer versions. Well
actually - starting with the GtkAda pre-installed with SuSE.
Of corse Gtk/GNOME it is a multi layer dependency hell.
Pango, Cairo, Gtk and all has to fit together. I has to try
quite a few combinations.
The aim is to provide the GPS. But ever since V. 2.x the
GPS eludes all my attemts. It won't even compile with GNAT/
Pro :-( .
"So LD_RUN_PATH wasn't ignored but it needs some more
tweaking."
Well, hat not so much luck. I guess I need another round
until r6 is ready.
Martin
Logged In: YES
user_id=697486
Hello Björn,
since you said it worked for you I had another look. The
problem arises when linking the pango which came with the
distribution. Well it might just be a 64 bit problem so
currenly I try:
%ifarch x86_64
case "%{System_Id}" in
(suse_10_)
declare -x LD_RUN_PATH=/opt/gnome/lib64
declare -x LD_LIBRARY_PATH=/opt/gnome/lib64
;;
()
;;
esac;
%endif
Honestly: I am not keen on delivering a Gtk toolchain and I
can get away with using the pre-installed version I allways
go for that.
Martin
Logged In: YES
user_id=697486
Hello Björn,
since you said it worked for you I had another look. The
problem arises when linking the pango which came with the
distribution. Well it might just be a 64 bit problem so
currenly I try:
%ifarch x86_64
case "%{System_Id}" in
(suse_10_)
declare -x LD_RUN_PATH=/opt/gnome/lib64
declare -x LD_LIBRARY_PATH=/opt/gnome/lib64
;;
()
;;
esac;
%endif
Honestly: I am not keen on delivering a Gtk toolchain and I
can get away with using the pre-installed version I allways
go for that.
Martin
Logged In: YES
user_id=697486
Hello Björn,
The compile for SuSE 10.1 worked fine. However: the
situation is different when compiling SuSE 9.2:
gtkplotgdk.c: In Funktion »gtk_plot_gdk_draw_string«:
gtkplotgdk.c:621: Fehler: »PangoMatrix« nicht deklariert
(erste Benutzung in dieser Funktion)
gtkplotgdk.c:621: Fehler: (Jeder nicht deklarierte
Bezeichner wird nur einmal aufgeführt
gtkplotgdk.c:621: Fehler: für jede Funktion in der er auftritt.)
gtkplotgdk.c:621: Fehler: expected »;« before »matrix«
gtkplotgdk.c:731: Fehler: »matrix« nicht deklariert (erste
Benutzung in dieser Funktion)
I will take the following course of action: Only provide a
Gtk+ for when realy needed.
Martin
Logged In: NO
OK, then I'll package GTK for Fedora only if I can't compile
GTKada otherwise.
Logged In: YES
user_id=697486
The upload is running - so I set it to pending.
Logged In: YES
user_id=1037163
I consider this problem fixed.
Logged In: YES
user_id=1037163
Originator: YES
Now you've done it again! Exactly the same problem as last time. RPMbuild requests libstdc++.so.6, which is found in /usr/lib. libstdc++ requires libgcc_s.so.1, and because of LD_LIBRARY_PATH that's picked up from /opt/gnat/gpl/lib. But Gnat/GPL 2007's libgcc_s is too old for GCC 4.1.1's libstdc++, so RPMbuild can't run.
Martin, you seriously need to read http://xahlee.org/UnixResource_dir/_/ldpath.html. Replacing basic system libraries under the feet of important system programs is not a good idea. If you really must use LD_LIBRARY_PATH you have to make a wrapper that sets it only for that particular program that actually needs it.
Logged In: YES
user_id=697486
Originator: NO
Well first ASIS should not be set (any more):
grep LD_LIBRARY_PATH *
Set_ASIS.bash: #LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ASIS_TOP}/lib
Set_ASIS.bash: # LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ASIS_TOP}
Set_ASIS.zsh: #LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ASIS_TOP}/lib
Set_ASIS.zsh: # LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${ASIS_TOP}
As for the rest: I have a closer look.
Martin
Logged In: YES
user_id=697486
Originator: NO
With R8 this should finaly be fixed.