Re: patch to autoconfiscate vfork handling

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Jeffrey A Law <law@cygnus.com>
 > 
 >   In message <199811090147.UAA07987@caip.rutgers.edu>you write:
 >   > 
 >   > 	Taken to its logical conclusion, this means that *none* of
 >   > libiberty.a is currently usable for binaries built in the gcc dir if
 >   > canadian crosses are to work.  (Until we do both host/build copies of
 >   > libiberty.a.)
 > 
 > Not exactly.
 > 
 > libiberty.a can be used for things which are for the host machine, but not
 > things for the build machine (using normal terminology, not gcc's backwards
 > terminology).
 > 
 > If there is build code relying on libiberty.a, then it needs to be changed
 > to build a suitable .o in the gcc directory using  stuff like this:
 > 
 > # Compile the libraries to be used by gen*.
 > # If we are not cross-building, gen* use the same .o's that cc1 will use,
 > # and HOST_PREFIX_1 is `foobar', just to ensure these rules don't conflict
 > # with the rules for rtl.o, alloca.o, etc.
 > $(HOST_PREFIX_1)rtl.o: $(srcdir)/rtl.c $(CONFIG_H) system.h $(RTL_H) bitmap.h
 >         rm -f $(HOST_PREFIX)rtl.c
 >         sed -e 's/config[.]h/hconfig.h/' $(srcdir)/rtl.c > $(HOST_PREFIX)rtl.c
 >         $(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(HOST_PREFIX)rtl.c
 > 
 > jeff


	Urg, this is confusing.  Is there some concise definition
describing "normal" terminology vs. gcc's "backwards" one?  (I assume
target always refers to the platform xgcc creates binaries for.)  So
the following are the two possible host/build definitions:

1.  The "host" system hosts the bootstrap.
    The "build" system is what you build the resulting xgcc for.

2.  The "host" system hosts the resulting xgcc binary.
    The "build" system is where you build xgcc.

	So it boils down to whether host/build refers to
bootstrap/xgcc or to xgcc/bootstrap?

	These definitions are opposite, and I'm not sure which is
which.  My guess is that #1 is gcc's "backwards" definition and #2 is
"normal". (?)

	Anyway, it sounds like you should be able to look at a file
and depending on whether it includes hconfig.h/config.h, you may or
may not link it with libiberty.a.  Which of hconfig.h/config.h makes
it possible, I still don't feel like I understand. :-)



	The specific example I am thinking of is in java/Makefile.
The jc1 and jv-scan binaries require obstack.o but don't link with it,
so they get it from libiberty.a.  The following patch adds
../obstack.o (or you might be able to use $(SUBDIR_OBSTACK)?)
My head hurts. :-)

		--Kaveh

PS: I cannot install into the java directory, so this patch is only
for reference.  You must come up with you own version of it, due to
the paperwork/legal restrictions. :-/



--- egcs-CVS19981028/gcc/java/Makefile.in.orig	Wed Oct 28 21:16:00 1998
+++ egcs-CVS19981028/gcc/java/Makefile.in	Wed Oct 28 21:34:39 1998
@@ -194,11 +194,11 @@ compiler: ../jc1$(exeext) ../jv-scan$(ex
 ../jc1$(exeext): $(P) $(JAVA_OBJS) $(OBJDEPS) $(LIBDEPS)
 	rm -f ../jc1$(exeext)
 	$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \
-	      $(JAVA_OBJS) $(OBJS) $(LIBS)
+	      $(JAVA_OBJS) $(OBJS) ../obstack.o $(LIBS)
 ../jv-scan$(exeext): $(P) $(JAVA_OBJS_LITE) $(OBJDEPS) $(LIBDEPS)
 	rm -f ../jv-scan$(exeext)
 	$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \
-	      $(JAVA_OBJS_LITE) $(LIBS)
+	      $(JAVA_OBJS_LITE) ../obstack.o $(LIBS)
 
 ../jcf-dump$(exeext): jcf-dump.o jcf-io.o jcf-depend.o jcf-path.o \
 		zextract.o