* libada multilb advice request
@ 2007-07-25 22:57 Joel Sherrill
2007-07-26 10:23 ` Richard Guenther
0 siblings, 1 reply; 7+ messages in thread
From: Joel Sherrill @ 2007-07-25 22:57 UTC (permalink / raw)
To: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]
Hi,
I am taking a stab at getting libada to build multilib
and I just don't seem to grok the magic. I am doing this
for RTEMS but the target shouldn't matter as long as
it is multilib'ed. Instructions for building GNAT/RTEMS are at
http://www.rtems.org/wiki/index.php/RTEMSAda
This works well except the Ada libraries are not multilibed.
I started by adding --enable-libada --enable-multilib
to our configures but that didn't do anything to libada.
As best I can tell, the top level configure/Makefile
magic is in place for libada to be multilib'ed but I
don't even see the multilib directory structure getting
created.
I have tried to edit libada/configure.ac and libada/Makefile.in
based upon the multilib magic I see in other top level
directories. So far no luck on even getting the multilib
structure generated in the build tree. The attached patch
has what I have so far along with the other RTEMS patches to 4.2.0.
I would really appreciate some hints. This is just
black magic.
Thanks.
--joel sherrill
[-- Attachment #2: libada-1.diff --]
[-- Type: text/x-patch, Size: 8210 bytes --]
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/gcc/ada/s-osinte-rtems.ads /home/joel/work-gnat/gcc-4.2.0/gcc/ada/s-osinte-rtems.ads
--- /home/joel/tools-original/gcc-4.2.0-ship/gcc/ada/s-osinte-rtems.ads 2005-06-30 20:29:17.000000000 -0500
+++ /home/joel/work-gnat/gcc-4.2.0/gcc/ada/s-osinte-rtems.ads 2007-07-02 15:22:30.000000000 -0500
@@ -291,12 +291,10 @@
sig : Signal) return int;
pragma Import (C, pthread_kill, "pthread_kill");
- type sigset_t_ptr is access all sigset_t;
-
function pthread_sigmask
(how : int;
- set : sigset_t_ptr;
- oset : sigset_t_ptr) return int;
+ set : access sigset_t;
+ oset : access sigset_t) return int;
pragma Import (C, pthread_sigmask, "pthread_sigmask");
----------------------------
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/arm/rtems-elf.h /home/joel/work-gnat/gcc-4.2.0/gcc/config/arm/rtems-elf.h
--- /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/arm/rtems-elf.h 2005-11-21 16:56:34.000000000 -0600
+++ /home/joel/work-gnat/gcc-4.2.0/gcc/config/arm/rtems-elf.h 2007-07-02 15:22:17.000000000 -0500
@@ -27,6 +27,7 @@
#define TARGET_OS_CPP_BUILTINS() \
do { \
builtin_define ("__rtems__"); \
+ builtin_define ("__USE_INIT_FINI__"); \
builtin_assert ("system=rtems"); \
} while (0)
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/c4x/rtems.h /home/joel/work-gnat/gcc-4.2.0/gcc/config/c4x/rtems.h
--- /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/c4x/rtems.h 2005-06-24 20:22:41.000000000 -0500
+++ /home/joel/work-gnat/gcc-4.2.0/gcc/config/c4x/rtems.h 2007-07-02 15:22:17.000000000 -0500
@@ -24,6 +24,5 @@
#define TARGET_OS_CPP_BUILTINS() \
do { \
builtin_define ("__rtems__"); \
- builtin_define ("__USE_INIT_FINI__"); \
builtin_assert ("system=rtems"); \
} while (0)
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/mips/elf.h /home/joel/work-gnat/gcc-4.2.0/gcc/config/mips/elf.h
--- /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/mips/elf.h 2006-10-08 02:35:47.000000000 -0500
+++ /home/joel/work-gnat/gcc-4.2.0/gcc/config/mips/elf.h 2007-07-02 15:22:17.000000000 -0500
@@ -49,6 +49,4 @@
#undef ENDFILE_SPEC
#define ENDFILE_SPEC "crtend%O%s crtn%O%s"
-#define NO_IMPLICIT_EXTERN_C 1
-
#define HANDLE_PRAGMA_PACK_PUSH_POP 1
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/sparc/sparc.c /home/joel/work-gnat/gcc-4.2.0/gcc/config/sparc/sparc.c
--- /home/joel/tools-original/gcc-4.2.0-ship/gcc/config/sparc/sparc.c 2006-04-14 02:01:38.000000000 -0500
+++ /home/joel/work-gnat/gcc-4.2.0/gcc/config/sparc/sparc.c 2007-07-02 15:22:17.000000000 -0500
@@ -703,7 +703,7 @@
error ("-mcmodel= is not supported on 32 bit systems");
}
- fpu = TARGET_FPU; /* save current -mfpu status */
+ fpu = target_flags & MASK_FPU; /* save current -mfpu status */
/* Set the default CPU. */
for (def = &cpu_default[0]; def->name; ++def)
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/libada/configure.ac /home/joel/work-gnat/gcc-4.2.0/libada/configure.ac
--- /home/joel/tools-original/gcc-4.2.0-ship/libada/configure.ac 2006-11-17 09:29:54.000000000 -0600
+++ /home/joel/work-gnat/gcc-4.2.0/libada/configure.ac 2007-07-25 16:45:16.000000000 -0500
@@ -21,6 +21,7 @@
AC_CONFIG_SRCDIR([Makefile.in])
sinclude(../config/acx.m4)
+sinclude(../config/multi.m4)
# Determine the host, build, and target systems
AC_CANONICAL_BUILD
@@ -30,6 +31,18 @@
# Determine the noncanonical target name, for directory use.
ACX_NONCANONICAL_TARGET
+AM_ENABLE_MULTILIB(, ..)
+
+dnl Default to --enable-multilib
+AC_ARG_ENABLE(multilib,
+[ --enable-multilib build many library versions (default)],
+[case "${enableval}" in
+ yes) multilib=yes ;;
+ no) multilib=no ;;
+ *) AC_MSG_ERROR(bad value ${enableval} for multilib option) ;;
+ esac], [test -z "$with_target_subdir" && multilib=no || multilib=yes])dnl
+
+
# Determine the target- and build-specific subdirectories
GCC_TOPLEV_SUBDIRS
@@ -79,6 +92,7 @@
esac
AC_SUBST([x_ada_cflags])
+
# Determine what to build for 'gnatlib'
if test $build = $target \
&& test ${enable_shared} = yes ; then
@@ -91,5 +105,20 @@
# Output: create a Makefile.
AC_CONFIG_FILES([Makefile])
+#AC_CONFIG_COMMANDS(
+# [if test -n "$CONFIG_FILES"; then
+# unset ac_file
+# echo "XXX JOEL1 ${srcdir}/../config-ml.in"
+# . ${srcdir}/../config-ml.in
+# fi],
+# [srcdir=${srcdir}
+# host=${host}
+# with_multisubdir=${with_multisubdir}
+# ac_configure_args="${multilib_arg} ${ac_configure_args}"
+# CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
+# CC="${CC}"
+# LDFLAGS="${LDFLAGS}"
+# ]
+#)
AC_OUTPUT
diff -ur /home/joel/tools-original/gcc-4.2.0-ship/libada/Makefile.in /home/joel/work-gnat/gcc-4.2.0/libada/Makefile.in
--- /home/joel/tools-original/gcc-4.2.0-ship/libada/Makefile.in 2006-11-17 09:29:54.000000000 -0600
+++ /home/joel/work-gnat/gcc-4.2.0/libada/Makefile.in 2007-07-25 15:14:12.000000000 -0500
@@ -15,8 +15,70 @@
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+libada_topdir = @libada_topdir@
+host_subdir = @host_subdir@
+
+# Multilib support variables.
+multi_basedir = @multi_basedir@
+TOP =
+MULTISRCTOP =
+MULTIBUILDTOP =
+MULTIDIRS =
+MULTISUBDIR =
+MULTIDO = true
+MULTICLEAN = true
+
# Default target; must be first.
-all: gnatlib
+all: stamp-gnatlib1 libjoel.a
+
+libjoel.a:
+ touch libjoel.a
+
+stamp-gnatlib1:
+ $(MAKE) -C $(GCC_DIR)/ada $(FLAGS_TO_PASS) \
+ GNATLIBFLAGS="$(GNATLIBFLAGS)" \
+ GNATLIBCFLAGS="$(GNATLIBCFLAGS)" \
+ TARGET_LIBGCC2_CFLAGS="$(TARGET_LIBGCC2_CFLAGS)" \
+ THREAD_KIND="$(THREAD_KIND)" \
+ TRACE="$(TRACE)" \
+ ../stamp-gnatlib1 && touch stamp-gnatlib1
+
+# XXX the DO=all in other examples
+all-multi:
+ # If this is the top-level multilib, build all the other
+ # multilibs.
+ $(MAKE) ; exec $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=all
+
+install-multi:
+ $(MULTIDO) $(AM_MAKEFLAGS) DO=install multi-do # $(MAKE)
+
+.MAKE .PHONY: all-multi install-multi
+
+mostlyclean-multi:
+ $(MULTICLEAN) $(AM_MAKEFLAGS) DO=mostlyclean multi-clean # $(MAKE)
+clean-multi:
+ $(MULTICLEAN) $(AM_MAKEFLAGS) DO=clean multi-clean # $(MAKE)
+distclean-multi:
+ $(MULTICLEAN) $(AM_MAKEFLAGS) DO=distclean multi-clean # $(MAKE)
+maintainer-clean-multi:
+ $(MULTICLEAN) $(AM_MAKEFLAGS) DO=maintainer-clean multi-clean # $(MAKE)
+
+## These cleaning rules are recursive. They should not be
+## registered as dependencies of *-am rules. For instance
+## otherwise running `make clean' would cause both
+## clean-multi and mostlyclean-multi to be run, while only
+## clean-multi is really expected (since clean-multi recursively
+## call clean, it already do the job of mostlyclean).
+mostlyclean: mostlyclean-multi
+clean: clean-multi
+distclean: distclean-multi
+maintainer-clean: maintainer-clean-multi
+
+.MAKE .PHONY: mostlyclean-multi clean-multi distclean-multi maintainer-clean-multi
+
+install-exec-am: install-multi
+## No uninstall rule?
+
# Standard autoconf-set variables.
SHELL = @SHELL@
@@ -29,6 +91,7 @@
enable_shared = @enable_shared@
LN_S=@LN_S@
+
# Variables for the user (or the top level) to override.
objext=.o
GNATLIBFLAGS= -W -Wall -gnatpg
@@ -66,6 +129,11 @@
include $(tmake_file)
endif
+MULTIDIR := $(shell $(CC) $(CFLAGS) -print-multi-directory)
+MULTIOSDIR := $(shell $(CC) $(CFLAGS) -print-multi-os-directory)
+
+MULTIOSSUBDIR := $(shell if test $(MULTIOSDIR) != .; then echo /$(MULTIOSDIR); fi)
+
FLAGS_TO_PASS = \
"MAKEOVERRIDES=" \
"LDFLAGS=$(LDFLAGS)" \
@@ -84,7 +152,7 @@
gnatlib: @default_gnatlib_target@
gnatlib-plain: $(GCC_DIR)/ada/Makefile
- test -f stamp-libada || \
+ $(MULTIDO) $(AM_MAKEFLAGS) test -f stamp-libada || \
$(MAKE) -C $(GCC_DIR)/ada $(FLAGS_TO_PASS) \
GNATLIBFLAGS="$(GNATLIBFLAGS)" \
GNATLIBCFLAGS="$(GNATLIBCFLAGS)" \
@@ -133,16 +201,6 @@
install-html:
-# Cleaning rules.
-mostlyclean:
-
-clean:
-
-distclean:
- $(RM) Makefile config.status config.log
-
-maintainer-clean:
-
# Rules for rebuilding this Makefile.
Makefile: $(srcdir)/Makefile.in config.status
CONFIG_FILES=$@ ; \
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libada multilb advice request
2007-07-25 22:57 libada multilb advice request Joel Sherrill
@ 2007-07-26 10:23 ` Richard Guenther
2007-07-26 15:09 ` Joel Sherrill
0 siblings, 1 reply; 7+ messages in thread
From: Richard Guenther @ 2007-07-26 10:23 UTC (permalink / raw)
To: Joel Sherrill; +Cc: GCC Patches
On 7/26/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> Hi,
>
> I am taking a stab at getting libada to build multilib
> and I just don't seem to grok the magic. I am doing this
> for RTEMS but the target shouldn't matter as long as
> it is multilib'ed. Instructions for building GNAT/RTEMS are at
> http://www.rtems.org/wiki/index.php/RTEMSAda
>
> This works well except the Ada libraries are not multilibed.
>
> I started by adding --enable-libada --enable-multilib
> to our configures but that didn't do anything to libada.
>
> As best I can tell, the top level configure/Makefile
> magic is in place for libada to be multilib'ed but I
> don't even see the multilib directory structure getting
> created.
>
> I have tried to edit libada/configure.ac and libada/Makefile.in
> based upon the multilib magic I see in other top level
> directories. So far no luck on even getting the multilib
> structure generated in the build tree. The attached patch
> has what I have so far along with the other RTEMS patches to 4.2.0.
>
> I would really appreciate some hints. This is just
> black magic.
Ada is not multilib capable.
Richard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libada multilb advice request
2007-07-26 10:23 ` Richard Guenther
@ 2007-07-26 15:09 ` Joel Sherrill
2007-07-26 15:11 ` Richard Guenther
0 siblings, 1 reply; 7+ messages in thread
From: Joel Sherrill @ 2007-07-26 15:09 UTC (permalink / raw)
To: Richard Guenther; +Cc: GCC Patches
Richard Guenther wrote:
> On 7/26/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>> Hi,
>>
>> I am taking a stab at getting libada to build multilib
>> and I just don't seem to grok the magic. I am doing this
>> for RTEMS but the target shouldn't matter as long as
>> it is multilib'ed. Instructions for building GNAT/RTEMS are at
>> http://www.rtems.org/wiki/index.php/RTEMSAda
>>
>> This works well except the Ada libraries are not multilibed.
>>
>> I started by adding --enable-libada --enable-multilib
>> to our configures but that didn't do anything to libada.
>>
>> As best I can tell, the top level configure/Makefile
>> magic is in place for libada to be multilib'ed but I
>> don't even see the multilib directory structure getting
>> created.
>>
>> I have tried to edit libada/configure.ac and libada/Makefile.in
>> based upon the multilib magic I see in other top level
>> directories. So far no luck on even getting the multilib
>> structure generated in the build tree. The attached patch
>> has what I have so far along with the other RTEMS patches to 4.2.0.
>>
>> I would really appreciate some hints. This is just
>> black magic.
>
> Ada is not multilib capable.
What exactly does you mean by this statement? I know the
current build structure doesn't build libada multilib and I
want to fix that. That was what the attached patch attempted
to do.
Is it explicitly disabled somewhere I missed?/
Embedded users whose target CPU doesn't match the
default CPU model end up custom building the
library. I want to get libada multilib'ed so this burden
isn't there.
--joel
>
> Richard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libada multilb advice request
2007-07-26 15:09 ` Joel Sherrill
@ 2007-07-26 15:11 ` Richard Guenther
2007-07-26 15:15 ` Richard Kenner
2007-07-26 15:23 ` Joel Sherrill
0 siblings, 2 replies; 7+ messages in thread
From: Richard Guenther @ 2007-07-26 15:11 UTC (permalink / raw)
To: Joel Sherrill; +Cc: GCC Patches
On 7/26/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> Richard Guenther wrote:
> > On 7/26/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> >> Hi,
> >>
> >> I am taking a stab at getting libada to build multilib
> >> and I just don't seem to grok the magic. I am doing this
> >> for RTEMS but the target shouldn't matter as long as
> >> it is multilib'ed. Instructions for building GNAT/RTEMS are at
> >> http://www.rtems.org/wiki/index.php/RTEMSAda
> >>
> >> This works well except the Ada libraries are not multilibed.
> >>
> >> I started by adding --enable-libada --enable-multilib
> >> to our configures but that didn't do anything to libada.
> >>
> >> As best I can tell, the top level configure/Makefile
> >> magic is in place for libada to be multilib'ed but I
> >> don't even see the multilib directory structure getting
> >> created.
> >>
> >> I have tried to edit libada/configure.ac and libada/Makefile.in
> >> based upon the multilib magic I see in other top level
> >> directories. So far no luck on even getting the multilib
> >> structure generated in the build tree. The attached patch
> >> has what I have so far along with the other RTEMS patches to 4.2.0.
> >>
> >> I would really appreciate some hints. This is just
> >> black magic.
> >
> > Ada is not multilib capable.
> What exactly does you mean by this statement? I know the
> current build structure doesn't build libada multilib and I
> want to fix that. That was what the attached patch attempted
> to do.
>
> Is it explicitly disabled somewhere I missed?/
>
> Embedded users whose target CPU doesn't match the
> default CPU model end up custom building the
> library. I want to get libada multilib'ed so this burden
> isn't there.
I was trying to say that even if you manage to build multilibs for libada,
the current gnat driver does not know how to use them. In fact, the
gnat driver(s) behave sufficiently different than all other gcc frontends
which results in funny bugs like PR29127 and PR30560.
(I certainly applaud any efforts to bring ada more in-line with the other
frontends in this regard)
Thanks,
Richard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libada multilb advice request
2007-07-26 15:11 ` Richard Guenther
@ 2007-07-26 15:15 ` Richard Kenner
2007-07-26 16:22 ` Joel Sherrill
2007-07-26 15:23 ` Joel Sherrill
1 sibling, 1 reply; 7+ messages in thread
From: Richard Kenner @ 2007-07-26 15:15 UTC (permalink / raw)
To: richard.guenther; +Cc: gcc-patches, joel.sherrill
> I was trying to say that even if you manage to build multilibs for libada,
> the current gnat driver does not know how to use them.
Sure, but there's a chicken-and-egg problem here: if you can't build
multilibs for Ada, who would bother to try to modify the driver to them?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libada multilb advice request
2007-07-26 15:11 ` Richard Guenther
2007-07-26 15:15 ` Richard Kenner
@ 2007-07-26 15:23 ` Joel Sherrill
1 sibling, 0 replies; 7+ messages in thread
From: Joel Sherrill @ 2007-07-26 15:23 UTC (permalink / raw)
To: Richard Guenther; +Cc: GCC Patches
Richard Guenther wrote:
> On 7/26/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>> Richard Guenther wrote:
>> > On 7/26/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>> >> Hi,
>> >>
>> >> I am taking a stab at getting libada to build multilib
>> >> and I just don't seem to grok the magic. I am doing this
>> >> for RTEMS but the target shouldn't matter as long as
>> >> it is multilib'ed. Instructions for building GNAT/RTEMS are at
>> >> http://www.rtems.org/wiki/index.php/RTEMSAda
>> >>
>> >> This works well except the Ada libraries are not multilibed.
>> >>
>> >> I started by adding --enable-libada --enable-multilib
>> >> to our configures but that didn't do anything to libada.
>> >>
>> >> As best I can tell, the top level configure/Makefile
>> >> magic is in place for libada to be multilib'ed but I
>> >> don't even see the multilib directory structure getting
>> >> created.
>> >>
>> >> I have tried to edit libada/configure.ac and libada/Makefile.in
>> >> based upon the multilib magic I see in other top level
>> >> directories. So far no luck on even getting the multilib
>> >> structure generated in the build tree. The attached patch
>> >> has what I have so far along with the other RTEMS patches to 4.2.0.
>> >>
>> >> I would really appreciate some hints. This is just
>> >> black magic.
>> >
>> > Ada is not multilib capable.
>> What exactly does you mean by this statement? I know the
>> current build structure doesn't build libada multilib and I
>> want to fix that. That was what the attached patch attempted
>> to do.
>>
>> Is it explicitly disabled somewhere I missed?/
>>
>> Embedded users whose target CPU doesn't match the
>> default CPU model end up custom building the
>> library. I want to get libada multilib'ed so this burden
>> isn't there.
>
> I was trying to say that even if you manage to build multilibs for
> libada,
> the current gnat driver does not know how to use them. In fact, the
> gnat driver(s) behave sufficiently different than all other gcc frontends
> which results in funny bugs like PR29127 and PR30560.
I fixed something like 29127 years ago in gnatmake.
I will look into both of them if I get the multilib working. Those
bugs do not appear to be holding up multilib'ing libada as best I
can tell.
>
> (I certainly applaud any efforts to bring ada more in-line with the other
> frontends in this regard)
>
Any suggestions on what might be preventing the configure/build from
even making multilib build directories for libada. Is there any explicit
disable I am missing?
> Thanks,
> Richard.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: libada multilb advice request
2007-07-26 15:15 ` Richard Kenner
@ 2007-07-26 16:22 ` Joel Sherrill
0 siblings, 0 replies; 7+ messages in thread
From: Joel Sherrill @ 2007-07-26 16:22 UTC (permalink / raw)
To: Richard Kenner; +Cc: richard.guenther, gcc-patches
Richard Kenner wrote:
>> I was trying to say that even if you manage to build multilibs for libada,
>> the current gnat driver does not know how to use them.
>>
>
> Sure, but there's a chicken-and-egg problem here: if you can't build
> multilibs for Ada, who would bother to try to modify the driver to them?
>
I don't see how the PRs mentioned indicate gnat doesn't
grok multilib's. I can see how there are issues since there
has to be some multilib magic on the linking in gnatmake
and/or gnatlink. But those are the PRs mentioned.
The patch attached to my first email is an attempt to
add the configure/Makefile magic but it isn't enough to
even get multilib directories generated for libada's
build tree. I have to get by that first.
-joel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-07-26 15:28 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-25 22:57 libada multilb advice request Joel Sherrill
2007-07-26 10:23 ` Richard Guenther
2007-07-26 15:09 ` Joel Sherrill
2007-07-26 15:11 ` Richard Guenther
2007-07-26 15:15 ` Richard Kenner
2007-07-26 16:22 ` Joel Sherrill
2007-07-26 15:23 ` Joel Sherrill
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).