Re: Multilib nightmares (breaking EGCS builds)

Re: Multilib nightmares (breaking EGCS builds)

[meissner]

| On open server, we have two modes of compilation. Normal and -mcoff.
| In normal mode, we support PIC, in -mcoff mode we dont. Gcc creates
| two libgcc.a's, one for normal and one for mcoff. Good. Now in the
| rest of egcs, I would expect the following:
| 1) A "normal" ELF libstdc++.a (and libio.a etc)
| 2) a PIC libstdc++.so and friends
| 3) an mcoff/libstdc++.a compiled with -mcoff.

At least as the sources currently exist on the Cygnus cvs server, none of the
x86 targets create multilib libraries.  The simplest way to check for
multilibing is to egrep for MULTI in the gcc/config/<machine> directory in the
t-* files.  The second way to check for multilibing is to issue:

	gcc -print-multi-lib

and if the only line it split out is:
	.;

your compiler doesn't do multilibing.  Given the above, I would expect the
following to be in gcc/config/t-sco5:

	MULTILIB_OPTIONS    = mcoff/melf fPIC
	MULTILIB_DIRNAMES   = coff elf pic
	MULTILIB_EXCEPTIONS = *mcoff*/*fPIC*
	MULTILIB_EXTRA_OPTS =

Then in your sco5.h file you would have:
	#define MULTILIB_DEFAULTS { "melf" }

if you wanted -melf to be the default (otherwise it would build libraries with
-melf and libraries with no specific switches).

Finally, go in and remove libgcc-elf.a and related rules, and change
LIBGCC_SPEC to not use libgcc-elf.a.

| It seems like configure is trying to do that. In the root of the egcs tree
| I have an mcoff directory, with libio and libstdc++ directories. libiberty
| is missing, and this causes the build to fail. Worse yet, the objects in
| mcoff/libio and mcoff/libstdc++ are ELRF objects, meaning they weren't
| even compiled with -mcoff. What is wrong? Am I missing makefile fragments
| or is the configuration process just plain wrong?
| 
| ANY help at all would be greatly appreciated.

Assuming you have multilibs set up, if it doesn't build multilib versions of
libstdc++.a, etc. then try --enable-multilib (old versions of the Cygnus tree
needed this, but I thought it had been fixed).

Note, this doesn't cover building a shared library out of libstdc++, just
getting the multilibs built for the static libraries.

Re: Multilib nightmares (breaking EGCS builds)

[J. Kean Johnston]

On Tue, 26 Aug 1997 meissner@cygnus.com wrote:

> your compiler doesn't do multilibing.  Given the above, I would expect the
> following to be in gcc/config/t-sco5:
> 
> 	MULTILIB_OPTIONS    = mcoff/melf fPIC
> 	MULTILIB_DIRNAMES   = coff elf pic
> 	MULTILIB_EXCEPTIONS = *mcoff*/*fPIC*
> 	MULTILIB_EXTRA_OPTS =
> 
> Then in your sco5.h file you would have:
> 	#define MULTILIB_DEFAULTS { "melf" }
Done. This works like a charm. I have just a few further questions, and I
can lay the Open Server multilib stuff to bed: How can I make fPIC and
fpic be the same, in terms of multilibbing? IE, both should use the
directory pic/. Also, what is the point of "elf" in the MULTILIB_DIRNAMES
variable? Surely I only need two directories: coff and pic. The elf
directory is not required as it is the default. I took a look at the
generated multilib.h and this does not seem to be the case. I have
included this generated file below, in case it helps you at all.

Thank you for your help so far ... it is much appreciated.

JKJ

static char *multilib_raw[] = {
". !mcoff !melf !fPIC;",
"coff mcoff !melf !fPIC;",
"elf !mcoff melf !fPIC;",
"pic !mcoff !melf fPIC;",
"elf/pic !mcoff melf fPIC;",
NULL
};

static char *multilib_matches_raw[] = {
"mcoff mcoff;",
"melf melf;",
"fPIC fPIC;",
NULL
};

static char *multilib_extra = "";

Re: Suggestion re: 970825 Snapshot Available

[Oleg Krivosheev]

On Mon, 25 Aug 1997, Joe Buck wrote:

> Date: Mon, 25 Aug 1997 17:13:53 -0700 (PDT)
> From: Joe Buck <jbuck@synopsys.com>
> To: Julian Seward <Julian_Seward@muraroa.demon.co.uk>
> Cc: law@cygnus.com, egcs@cygnus.com
> Subject: Re: Suggestion re: 970825 Snapshot Available
> 
> 
> > Would you consider compressing egcs with a better compressor?  The
> > question would be a bit academic but for the fact that I can offer you
> > such a beast.  It's GNU GPL'd, patent-free, reasonably fast, portable,
> > and command-line compatible with gzip.
> 
> > The compressor's called "bzip2"; an early version of it has seen
> > some use in the Linux community over the past year.
> 
> Sorry, bzip is not patent-free; it is most emphatically covered by a patent.
> Unless bzip2 has nothing at all in common with bzip, it cannot be used.

from recent announcement in c.o.l.a looks like 
bzip2 author dropped arithmetic compression
thus removing patent dependance.

regards

OK

One more MULTILIB question

[J. Kean Johnston]

Hi again.

This is just a thought, I know it is not currently part of the multilib
functionality. To my mind, it would make sense if it were possible not
only to generate maultiple versions of libgcc.a, but also the crt stuff.
For each libgcc.a generated, to have corresponding crtbegin.o and crtend.o
objects generated, compiled with the same flags. This could be very
useful, and is consistant. Even if there is no difference between the
objects, the location thereof is still more intuitive and provides more
functionality. In the case of Open Server, and I am sure other platforms
too, this could be very useful. The COFF and ELF crt*.o files are very
different between the two file formats.

Just a thought.

JKJ

Re: egcs-970825, all languages still built in stage1

[Alexandre Oliva]

--Multipart_Tue_Aug_26_01:00:59_1997-1
Content-Type: text/plain; charset=US-ASCII

Kaveh R Ghazi writes:

>> Kaveh R Ghazi writes:
>> 
>> > 	For egcs-970825, I did (setenv CC cc;./configure) make.  It tried
>> > to build fortran in stage1 and choked.

>> #if !defined (__GNUC__) || (__GNUC__ < 2)
>> #error "You have to use gcc 2.x to build g77 (might be fixed in g77-0.6)."
>> #endif

> 	If cc is used for stage1 and fortran is built in stage1, it
> won't work.  :-)

I see.  Well, I encountered another problem.  I build egcs for several
different architectures from a single --srcdir, and the build failed
just after creating libgcc.a

The attached patch seems to fix this problem.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

--Multipart_Tue_Aug_26_01:00:59_1997-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="f-srcdir.diff"
Content-Transfer-Encoding: 7bit

	* gcc/f/Make-lang.in: replace ../../$(srcdir) with $(srcdir),
	that is supposed to be the gcc directory

--- gcc/f/Make-lang.in	Mon Aug 25 12:33:36 1997
+++ gcc/f/Make-lang.in	Tue Aug 26 00:40:17 1997
@@ -346,9 +346,9 @@
 	  --no-validate news0.texi -o NEWS
 
 $(srcdir)/f/runtime/configure: $(srcdir)/f/runtime/configure.in 
-	cd f/runtime && $(MAKE) srcdir=../../$(srcdir)/f/runtime -f ../../$(srcdir)/f/runtime/Makefile.in rebuilt
+	cd f/runtime && $(MAKE) srcdir=$(srcdir)/f/runtime -f $(srcdir)/f/runtime/Makefile.in rebuilt
 $(srcdir)/f/runtime/libU77/configure: $(srcdir)/f/runtime/libU77/configure.in
-	cd f/runtime && $(MAKE) srcdir=../../$(srcdir)/f/runtime -f ../../$(srcdir)/f/runtime/Makefile.in rebuilt
+	cd f/runtime && $(MAKE) srcdir=$(srcdir)/f/runtime -f $(srcdir)/f/runtime/Makefile.in rebuilt
 
 f77.rebuilt: $(srcdir)/f/g77.info $(srcdir)/f/BUGS $(srcdir)/f/INSTALL \
   $(srcdir)/f/NEWS $(srcdir)/f/runtime/configure \
@@ -494,11 +494,11 @@
 f77.mostlyclean:
 	-rm -f f/*$(objext)
 	-rm -f f/fini f/f771 f/stamp-str f/str-*.h f/str-*.j f/intdoc
-	-cd f/runtime; $(MAKE) -f ../../$(srcdir)/f/runtime/Makefile.in mostlyclean
+	-cd f/runtime; $(MAKE) -f $(srcdir)/f/runtime/Makefile.in mostlyclean
 f77.clean:
-	-cd f/runtime; $(MAKE) -f ../../$(srcdir)/f/runtime/Makefile.in clean
+	-cd f/runtime; $(MAKE) -f $(srcdir)/f/runtime/Makefile.in clean
 f77.distclean:
-	-cd f/runtime; $(MAKE) -f ../../$(srcdir)/f/runtime/Makefile.in distclean
+	-cd f/runtime; $(MAKE) -f $(srcdir)/f/runtime/Makefile.in distclean
 	-rm -f f/Makefile
 # like gcc's extraclean, which does clean f/ for us, but not f/gbe,
 # f/runtime, f/runtime/libF77, f/runtime/libI77, and f/runtime/libU77,
@@ -516,7 +516,7 @@
 	-rm -f f/*/*/*lose f/*/*/*.s f/*/*/*.s[0-9] f/*/*/*.i
 # realclean is the pre-2.7.0 name for maintainer-clean
 f77.maintainer-clean f77.realclean: f77.distclean
-	-cd f/runtime; $(MAKE) -f ../../$(srcdir)/f/runtime/Makefile.in maintainer-clean
+	-cd f/runtime; $(MAKE) -f $(srcdir)/f/runtime/Makefile.in maintainer-clean
 	-$(MAKE) f77.maintainer-clean
 	-rm -f f/g77.info* f/g77.*aux f/TAGS f/BUGS f/INSTALL f/NEWS f/intdoc.texi
 # Stage hooks:

--Multipart_Tue_Aug_26_01:00:59_1997-1--

Re: Multilib nightmares (breaking EGCS builds)

[meissner]

| > your compiler doesn't do multilibing.  Given the above, I would expect the
| > following to be in gcc/config/t-sco5:
| > 
| > 	MULTILIB_OPTIONS    = mcoff/melf fPIC
| > 	MULTILIB_DIRNAMES   = coff elf pic
| > 	MULTILIB_EXCEPTIONS = *mcoff*/*fPIC*
| > 	MULTILIB_EXTRA_OPTS =
| > 
| > Then in your sco5.h file you would have:
| > 	#define MULTILIB_DEFAULTS { "melf" }
| Done. This works like a charm. I have just a few further questions, and I
| can lay the Open Server multilib stuff to bed: How can I make fPIC and
| fpic be the same, in terms of multilibbing? IE, both should use the
| directory pic/.

I just answered that in another message (ie, using MULTILIB_MATCHES).

|		  Also, what is the point of "elf" in the MULTILIB_DIRNAMES
| variable? Surely I only need two directories: coff and pic. The elf
| directory is not required as it is the default. I took a look at the
| generated multilib.h and this does not seem to be the case. I have
| included this generated file below, in case it helps you at all.

The MULTILIB_OPTIONS & MULTILIB_DIRNAMES lines above would want to create the
following directories:

	<dir>		no switches
	<dir>/coff	-mcoff
	<dir>/elf	-melf
	<dir>/coff/pic	-mcoff -fPIC
	<dir>/elf/pic	-melf -fPIC
	<dir>/pic	-fPIC

The MULTILIB_EXCEPTIONS line prevents -mcoff -fPIC from being generated.

The MULTILIB_DEFAULTS define in the .h file says what defaults are turned on by
default.  The compiler then doesn't have to build anything that uses that
directory (ie, <dir>/elf and <dir>/elf/pic above).  This is useful if you
wanted different .h files to use the same t-* file.  For example, using the
rs6000/powerpc configurations, if you configure for:

	powerpc-eabi

the default is for -mcall-sysv, so it doesn't build those directories.  If
however, you configured it via:

	powerpc-eabiaix

it would set the default to -mcall-aix.  Both of these use the same t-* files,
but powerpc-eabi uses the eabi.h config file, while powerpc-eabiaix uses the
eabiaix.h config file.  If you aren't going to need that ability, you could
define the make variables as (assuming -melf is default):

	MULTILIB_OPTIONS  = mcoff/fPIC
	MULTILIB_DIRNAMES = coff pic
	MULTLIB_MATCHES   = fPIC=fpic

Re: Multilib nightmares (breaking EGCS builds)

[meissner]

| your compiler doesn't do multilibing.  Given the above, I would expect the
| following to be in gcc/config/t-sco5:
| 
| 	MULTILIB_OPTIONS    = mcoff/melf fPIC
| 	MULTILIB_DIRNAMES   = coff elf pic
| 	MULTILIB_EXCEPTIONS = *mcoff*/*fPIC*
| 	MULTILIB_EXTRA_OPTS =

You probably also want:

	MULTILIB_MATCHES = fPIC=fpic

so that use of either -fpic or -fPIC will use the libraries compiled with
-fPIC.

Multilib nightmares (breaking EGCS builds)

[J. Kean Johnston]

Ho hum.

Just figures out multilibbing in GCC. Made Open Server use it.
All is happy in GCC land. Not so for the rest of EGCS. Here's
what I've got on Open Server. I dont think its an OS specific problem, so
someone with more knowledge of the makefiles and multilib stuff should
probably look into this.

On open server, we have two modes of compilation. Normal and -mcoff.
In normal mode, we support PIC, in -mcoff mode we dont. Gcc creates
two libgcc.a's, one for normal and one for mcoff. Good. Now in the
rest of egcs, I would expect the following:
1) A "normal" ELF libstdc++.a (and libio.a etc)
2) a PIC libstdc++.so and friends
3) an mcoff/libstdc++.a compiled with -mcoff.

It seems like configure is trying to do that. In the root of the egcs tree
I have an mcoff directory, with libio and libstdc++ directories. libiberty
is missing, and this causes the build to fail. Worse yet, the objects in
mcoff/libio and mcoff/libstdc++ are ELRF objects, meaning they weren't
even compiled with -mcoff. What is wrong? Am I missing makefile fragments
or is the configuration process just plain wrong?

ANY help at all would be greatly appreciated.

JKJ