Does anyone know what that warning means? That Fedora wouldn't support
libraries is just plain wrong. Has Gnat somehow been built without support
for libraries?
--
Bj�rn Persson
PGP key A88682FD
This indicates that GCC was compiled with the wrong version of mlib-
tgt.adb. In GCC 4.4, the proper version was renamed from mlib-tgt-
linux.adb to mlib-tgt-specific-linux.adb. I know because I had to
fix this problem for the Debian package, which is now in the NEW queue
awaiting inspection by an FTP master.
--
Ludovic Brenta.
> This indicates that GCC was compiled with the wrong version of mlib-
> tgt.adb. In GCC 4.4, the proper version was renamed from mlib-tgt-
> linux.adb to mlib-tgt-specific-linux.adb. I know because I had to
> fix this problem for the Debian package, which is now in the NEW queue
> awaiting inspection by an FTP master.
Thank you Ludovic. Now I can write a good bug report.
Out of curiosity, does Fedora include GNAT by default or did your
package come from a third party repository?
--
Ludovic Brenta.
> Out of curiosity, does Fedora include GNAT by default or did your
> package come from a third party repository?
>
Fedora includes GNAT and GtkAda by default.
Funny that you say - the Mac OS X 4.3 says the same.
Martin
--
mailto://kris...@users.sourceforge.net
Ada programming at: http://ada.krischik.com
> Björn Persson schrieb:
> > I have a problem with Gnat of GCC 4.4.0 on Fedora 11. When Gnatmake
> > encounters a Library_Name attribute in a project file, it says "warning:
> > libraries are not supported on this platform", and I can't get it to
> > generate any shared libraries.
>
> Funny that you say - the Mac OS X 4.3 says the same.
>
> Martin
I have seen same with GNAT GPL 2008 on Windows and FSF GCC 4.5 on OpenBSD.
The warning comes from gcc/ada/prj-nmsc.adb:
> if Data.Library then
> if Get_Mode = Multi_Language then
> Support_For_Libraries := Data.Config.Lib_Support;
>
> else
> Support_For_Libraries := MLib.Tgt.Support_For_Libraries;
> end if;
>
> if Support_For_Libraries = Prj.None then
> Error_Msg
> (Project, In_Tree,
> "?libraries are not supported on this platform",
> Lib_Name.Location);
> Data.Library := False;
>
> else
...
--
Tero Koskinen - http://iki.fi/tero.koskinen/
> Björn Persson schrieb:
> > I have a problem with Gnat of GCC 4.4.0 on Fedora 11. When Gnatmake
> > encounters a Library_Name attribute in a project file, it says "warning:
> > libraries are not supported on this platform", and I can't get it to
> > generate any shared libraries.
>
> Funny that you say - the Mac OS X 4.3 says the same.
Shared libraries work OK on Mac OS X [1], so I guess it's a limitation
of GNAT project files on the platform.
[1] <http://home.roadrunner.com/~jbmatthews/misc/shared.html>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
gprbuild is quite capable of building shared libraries on (intel) Mac
OS X with both GCC 4.3.3 and GNAT GPL 2009. So is gnatmake so long as
there are only Ada sources.
Where there is an issue is with locating the shared libraries at run
time. GNAT GPL 2009 gets this right - to an extent - but sometimes
it's easier to just set DYLD_LIBRARY_PATH.
Or to use static libraries!
Ludovic Brenta schrieb:
So, how did you fix it?
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKSIhjijwKaHyem9cRAicYAKDvilICqjjj4Y9NBcCsWq+uv77GCwCeIYHQ
gsmWpPFFU6sI5CDDvievsKg=
=lYYB
-----END PGP SIGNATURE-----
By adjusting the TOOLS_TARGET_PAIRS in src/gcc/ada/gcc-interface/
Makefile.in where mlib-tgt{,-specific} appears. In Debian, this is
actually part of a much larger and invasive patch that builds
libgnatprj, the project manager library used by all GNAT tools and by
GPS, so the TOOLS_TARGET_PAIRS are now in src/libgnatprj/Makefile.in.
(Note that the value of TOOLS_TARGET_PAIRS depends on the target
triplet).
Since the pristine version of src/gcc/ada/gcc-interface/Makefile.in
seems fine, I think the problem on Fedora 11 was triggered by a patch
that was not adjusted for the change from mlib-tgt to mlib-tgt-
specific.
--
Ludovic Brenta.
> By adjusting the TOOLS_TARGET_PAIRS in src/gcc/ada/gcc-interface/
> Makefile.in where mlib-tgt{,-specific} appears. In Debian, this is
> actually part of a much larger and invasive patch that builds
> libgnatprj, the project manager library used by all GNAT tools and by
> GPS, so the TOOLS_TARGET_PAIRS are now in src/libgnatprj/Makefile.in.
> (Note that the value of TOOLS_TARGET_PAIRS depends on the target
> triplet).
>
> Since the pristine version of src/gcc/ada/gcc-interface/Makefile.in
> seems fine, I think the problem on Fedora 11 was triggered by a patch
> that was not adjusted for the change from mlib-tgt to mlib-tgt-
> specific.
I've finally found the error. It's in gnattools/Makefile.in. It makes
symbolic links pointing to the wrong directory. This is the patch I applied:
--- gnattools/Makefile.in~ 2009-04-14 16:25:44.000000000 +0200
+++ gnattools/Makefile.in 2009-07-25 04:31:38.000000000 +0200
@@ -164,7 +164,7 @@
-(cd $(GCC_DIR)/ada/tools; $(LN_S) ../sdefault.adb .)
-$(foreach PAIR,$(TOOLS_TARGET_PAIRS), \
rm -f $(GCC_DIR)/ada/tools/$(word 1,$(subst <, ,$(PAIR)));\
- $(LN_S) $(fsrcdir)/$(word 2,$(subst <, ,$(PAIR))) \
+ $(LN_S) $(fsrcdir)/ada/$(word 2,$(subst <, ,$(PAIR))) \
$(GCC_DIR)/ada/tools/$(word 1,$(subst <, ,$(PAIR)));)
touch $(GCC_DIR)/stamp-tools
It wasn't caused by a Fedora patch. The error is present in the GCC 4.4.0
release, but it's been fixed in 4.4.1.
I can't see that TOOLS_TARGET_PAIRS in gcc/ada/gcc-interface/Makefile.in is
used for anything. The value of TOOLS_TARGET_PAIRS in gnattools/Makefile.in
most likely comes from gnattools/configure. But the GCC build system is deep
magic to me so I may have missed something.
That explains why several people saw it on other platforms (OpenBSD
and Mac OS X were mentioned), whereas Debian never had the problem.
The Debian patches hide it by replacing gnattools/Makefile.in almost
completely.
> I can't see that TOOLS_TARGET_PAIRS in gcc/ada/gcc-interface/Makefile.in is
> used for anything. The value of TOOLS_TARGET_PAIRS in gnattools/Makefile.in
> most likely comes from gnattools/configure. But the GCC build system is deep
> magic to me so I may have missed something.
Mmh, that's a good point. I cannot see any references to gcc/ada/gcc-
interface/Makefile.in's TOOLS_TARGET_PAIRS either. I think this is
worth reporting upstream.
--
Ludovic Brenta.
> Today I got update of gcc-gnat, libgnat and libgnat-devel and problem
> is gone.
And in the changelog there's a reference to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40166, where I see that the
problem was identified and fixed a month before I first encountered it. I
could have saved a lot of time by searching in GCC Bugzilla. Oh well, it's
easy to be wise after the event.