[parisc-linux] phase 2 gcc build fails

[parisc-linux] phase 2 gcc build fails

[Matt Taggart]

Hi,

I'm trying to build an new cross-compiler and have run into the following 
errors,

gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/al-76/puffin/palinux/gcc/libiberty/..
/include  -W -Wall -Wtraditional -pedantic /home/al-76/puffin/palinux/gcc/libib
erty/argv.c
In file included from /home/al-76/puffin/palinux/gcc/libiberty/argv.c:26:
/home/al-76/puffin/palinux/gcc/libiberty/../include/libiberty.h:22: parse error
before `ATTRIBUTE_MALLOC'
/home/al-76/puffin/palinux/gcc/libiberty/../include/libiberty.h:22: warning: 
type defaults to `int' in declaration of `ATTRIBUTE_MALLOC'
/home/al-76/puffin/palinux/gcc/libiberty/../include/libiberty.h:22: ANSI C 
forbids data definition with no type or storage class

it complains about lines 22, 31, 55, 72, 76, 143, 154, 158, 162 all lines with 
"ATTRIBUTE_MALLOC". It didn't do this when I last built on December 11th so I 
think it must be something checked in since then. I have looked at the stuff 
that was checked in and it's not clear to me what's causing it.

Anyone have an idea?

-- 
Matt Taggart
taggart@fc.hp.com

Re: [parisc-linux] phase 2 gcc build fails

[Alan Modra]

On Wed, 13 Dec 2000, Matt Taggart wrote:

> Anyone have an idea?

I probably broke the CVS repo, when I ran "cvs admin -b" following your
updated recipe.  I do have a checked-out tree, to probably can put things
back as they were.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] phase 2 gcc build fails

[Matt Taggart]

Alan Modra writes...

> On Wed, 13 Dec 2000, Matt Taggart wrote:
> 
> > Anyone have an idea?
> 
> I probably broke the CVS repo, when I ran "cvs admin -b" following your
> updated recipe.  I do have a checked-out tree, to probably can put things
> back as they were.

Since admin -b reverts the default branch, wouldn't importing cygnus source 
fix things?

* taggart gets out the mang-signal

-- 
Matt Taggart
taggart@fc.hp.com

Re: [parisc-linux] phase 2 gcc build fails

[Alan Modra]

On Wed, 13 Dec 2000, Matt Taggart wrote:

> Alan Modra writes...
> 
> > I probably broke the CVS repo, when I ran "cvs admin -b" following your
> > updated recipe.  I do have a checked-out tree, to probably can put things
> > back as they were.
> 
> Since admin -b reverts the default branch, wouldn't importing cygnus source 
> fix things?

It looks like an import was done at some stage without merging stuff back
to the main trunk.  eg.

File: config.if         Status: Needs Patch

   Working revision:    1.1.1.2
   Repository revision: 1.1     /home/cvs/parisc/gcc/config.if,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

   Existing Tags:
        before20000925merge             (revision: 1.1.1.2)
        before20000822merge             (revision: 1.1.1.2)
        gcc-2_96-gnu-20000707           (revision: 1.1.1.2)
        GNU_DIST                        (branch: 1.1.1)
        gcc-2_9-hppa-20000707           (branch: 1.1.1.1.4)
        pre_fest                        (revision: 1.1.1.1)
        ELF_BRANCH                      (branch: 1.1.1.1.2)
        ELF_BASE                        (revision: 1.1.1.1)
        initial_checkin                 (revision: 1.1.1.1)
        gcc-2_9-hppa-991112             (branch: 1.1.1)

What I've got to do, I guess, is to commit my tree back to the main truck.
eg. in the case of config.if, we want a version 1.2 which will be identcal
to version 1.1.1.2

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] phase 2 gcc build fails

[Alan Modra]

On Thu, 14 Dec 2000, Alan Modra wrote:

> What I've got to do, I guess, is to commit my tree back to the main truck.
> eg. in the case of config.if, we want a version 1.2 which will be identcal
> to version 1.1.1.2

Seemed to work OK.  A "cvs update -d" in your gcc directory should now
fix your tree for you.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] phase 2 gcc build fails

[Michael Ang]

Yeah, that's exactly what you wanted to do.  After you ran the "admin
-b" command, the vendor branch was de-vendorised, so I'm guessing that
the next time you pulled you got the trunk, not the branch.  With vendor
branches, you never really know if you're pulling from a branch or the
trunk, hence our desire to avoid them.

	- Mike.

Alan Modra wrote:
> 
> On Thu, 14 Dec 2000, Alan Modra wrote:
> 
> > What I've got to do, I guess, is to commit my tree back to the main truck.
> > eg. in the case of config.if, we want a version 1.2 which will be identcal
> > to version 1.1.1.2
> 
> Seemed to work OK.  A "cvs update -d" in your gcc directory should now
> fix your tree for you.

Re: [parisc-linux] phase 2 gcc build fails

[Alan Modra]

On Thu, 14 Dec 2000, Michael Ang wrote:

> Yeah, that's exactly what you wanted to do.  After you ran the "admin
> -b" command, the vendor branch was de-vendorised, so I'm guessing that
> the next time you pulled you got the trunk, not the branch.  With vendor
> branches, you never really know if you're pulling from a branch or the
> trunk, hence our desire to avoid them.

For answering, you're the lucky recipient of another question :-)

Is it possible to import a vendor branch that contains new files, without
them magically appearing when checking out the HEAD version?  I've just
done an import from sourceware, then had to rm all the new files, cvs rm,
cvs commit.  Which is a pain.  Also, unless people use "checkout -P", they
get empty directories.

Regards, Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] phase 2 gcc build fails

[Matthew Wilcox]

On Thu, Dec 14, 2000 at 05:55:54PM +1100, Alan Modra wrote:
> Is it possible to import a vendor branch that contains new files, without
> them magically appearing when checking out the HEAD version?  I've just
> done an import from sourceware, then had to rm all the new files, cvs rm,
> cvs commit.  Which is a pain.  Also, unless people use "checkout -P", they
> get empty directories.

this isn't an answer to your question, but...

cvs rm -f file both rm's it and removes it from the repository (obviously,
you need to cvs ci afterwards).
the cvsrc we distribute in the build-tools repository has -P for cvs up.

unfortunately, cvs doesn't seem to take the `-f' option from the .cvsrc
for the rm command.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] phase 2 gcc build fails

[Michael Ang]

I implied this in my previous message, but you want to put "remove -f"
in you .cvsrc.  Of course, forgetting there's even a long form at all is
a sign of strength, not weakness. :)

	- Mike.

Matthew Wilcox wrote:
> 
> unfortunately, cvs doesn't seem to take the `-f' option from the .cvsrc
> for the rm command.

Re: [parisc-linux] phase 2 gcc build fails

[Michael Ang]

Alan Modra wrote:
> 
> > Yeah, that's exactly what you wanted to do.  After you ran the "admin
> > -b" command, the vendor branch was de-vendorised, so I'm guessing that
> > the next time you pulled you got the trunk, not the branch.  With vendor
> > branches, you never really know if you're pulling from a branch or the
> > trunk, hence our desire to avoid them.
> 
> For answering, you're the lucky recipient of another question :-)

Heh, serves me right ;)
 
> Is it possible to import a vendor branch that contains new files, without
> them magically appearing when checking out the HEAD version?  I've just
> done an import from sourceware, then had to rm all the new files, cvs rm,
> cvs commit.  Which is a pain.  Also, unless people use "checkout -P", they
> get empty directories.

Hmm, I didn't realise that this was another side effect of "import".  I
generally use "add" on the branch instead, which does the right thing
for new files.  So I guess when updating a third-party branch you have
two choices:
1. Use "import", and both "admin -b" and "cvs rm" from the trunk any new
files.
2. Use "add" on the branch, and "cvs rm" any removed files from the
branch.

New files on the trunk that shouldn't be there are probably less of a
nuisance than persistent files that should be gone, but there's no need
to make this kind of mistake.

If people want to prune empty directories they should use "checkout
-P".  Here's the contents of my .cvsrc:
cvs -z3
diff -uN
remove -f

I don't turn on "checkout -P" or "update -d" by default, but that's just
me.  I've been meaning to set up a checkout module for the kernel that
would include the minimal set of stuff you need to build for PA-RISC,
omitting the other arch dependent junk.  I plan to do it Real Soon Now.

	- Mike.