headers
Hubert Feyrer | 3 Jan 2003 15:58
Picon

1.6: how to build a (cross-)toolchain for amiga?


I'd like to rebuid the amiga's miniroot. trying to do a

	./build -m amiga -t

gives me:

	...
	f=/usr/cvs/src-1.6/tools/toolchain/../../gnu/dist/toolchain/gas/config/m68k-parse.y;
	if [ $f = "./config/m68k-parse.y" ]; then  ln -s config/m68k-parse.y . >
	/dev/null 2>/dev/null ||  ln config/m68k-parse.y . > /dev/null 2>/dev/null
	||  cp config/m68k-parse.y . >/dev/null 2>/dev/null;  f=m68k-parse.y;
	else true; fi;  /bin/sh
	/usr/cvs/src-1.6/tools/toolchain/../../gnu/dist/toolchain/gas/../ylwrap
	"bison -y" $f y.tab.c m68k-parse.c --;  if [ $f = "m68k-parse.y" ]; then
	rm -f m68k-parse.y;  else true; fi
	Shared object "libiconv.so.2" not found
	*** Error code 1

I have no idea where this comes from, and how to get to the point to get
to that place again to look into it further. Doing a simple 'make' doesn't
do it, obviously.

This is on the 1.6-stable branch btw, so I guess that shouldn't happen.

FWIW, I have the libiconv-1.8 package installed. Maybe some GNU configure
script picked that up by accident...

Help!
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Klausner | 3 Jan 2003 16:02
Picon

Re: 1.6: how to build a (cross-)toolchain for amiga?

On Fri, Jan 03, 2003 at 03:58:12PM +0100, Hubert Feyrer wrote:
> 	Shared object "libiconv.so.2" not found
> 	*** Error code 1
> 
> I have no idea where this comes from, and how to get to the point to get
> to that place again to look into it further. Doing a simple 'make' doesn't
> do it, obviously.

Try if it is bison's fault. Just running 'bison' will tell you.
If so, recompile bison.
 Thomas
--

-- 
Thomas Klausner - wiz <at> danbala.ifoer.tuwien.ac.at
What is wanted is not the will to believe, but the will to find
out, which is the exact opposite. -- Bertrand Russell
Permalink | Reply | 2 comments |
headers
Chris Pinnock | 4 Jan 2003 00:57

Re: 1.6: how to build a (cross-)toolchain for amiga?

On Fri, Jan 03, 2003 at 04:02:15PM +0100, Thomas Klausner wrote:
> On Fri, Jan 03, 2003 at 03:58:12PM +0100, Hubert Feyrer wrote:
> > 	Shared object "libiconv.so.2" not found
> > 	*** Error code 1
> > 
> > I have no idea where this comes from, and how to get to the point to get
> > to that place again to look into it further. Doing a simple 'make' doesn't
> > do it, obviously.
> 
> Try if it is bison's fault. Just running 'bison' will tell you.
> If so, recompile bison.

I don't think build.sh should be using bison. IIRC, something like this
was fixed in -current recently (i.e. so that our yacc was used whether
bison is present or not).

best wishes,
Chris
Permalink | Reply | 1 comment |
headers
Krister Walfridsson | 4 Jan 2003 11:43
Picon
Picon
Picon
Favicon

Re: 1.6: how to build a (cross-)toolchain for amiga?


On Fri, 3 Jan 2003, Chris Pinnock wrote:

> I don't think build.sh should be using bison. IIRC, something like this
> was fixed in -current recently (i.e. so that our yacc was used whether
> bison is present or not).

The generated files are already checked in for the GNU tools, so they
should not need to be re-generated at all. CVS does however (under some
conditions) not set the correct time on the files, and thus fool make to
re-generate them.

The GCC project solves this by providing a script that updates the source
by CVS, and then touches the generated files. I think we should do
something similar. I suggest that we add some magic to the build
process that touches those files if the generated files are older than
the source files. (This should of course be done in such a way that it
is easy to disable in case you really want to regenerate those files.)

   /Krister
Permalink | Reply | 0 comments |
headers
Lloyd Parkes | 9 Jan 2003 00:21
Picon

I've been playing with GCC 3.2/3.2.1

Just some random thoughts, and commentary on a couple of speed bumps.

I have ld from binutils 2.13 installed in /usr/local/bin and GCC 3.2.1 
installed in /usr/local/.... I have deleted /usr/bin/gcc, /usr/bin/g++, 
/usr/local/bin/cc and /usr/local/bin/c++. This gives me a system C compiler 
called cc and the GNU addon called gcc, just like every other computer I use. 
This distinction becomes important because of ABI changes in C++ (not that I 
know what those changes are).

The C compiler seems to work really well. At least one codegen bug has been 
fixed, and I'm going to start checking one or two other codegen bugs I found 
in 2.95.3.

The C++ compiler seems to have a problem because binaries it builds use 
libgcc, and it looks as if the shared version of libgcc is built with non-PIC 
code. The error I get is 'Undefined symbol "" (reloc type = 12, symnum = 21)', 
but I haven't bothered trying to find out what this means. Using 
-static-libgcc works, and I have noticed that libgcc.mk seems to use the same 
.o files for libgcc.a and libgcc_s.so.1.

The NetBSD gcc prints out its version number as '2.95.3' while GCC 3.2.1 
prints several lines of text and warranty information. This causes 
pkgsrc/lang/gcc/buildlink2.mk to become unhappy.

Cheers,
Lloyd
Permalink | Reply | 0 comments |
headers
Harlan Stenn | 17 Jan 2003 06:05
X-Face
Favicon

(b)make enhancement

I'm trying to convert GNU and FreeBSD makefiles to netbsd makefiles (really
bmake makefiles).

One thing that would really help me is .error (which is in FreeBSD) as well
as .warn (which is not).

I have working patches to the code and man page, and Simon tells me I should
float the idea here first.

I hope this isn't a bikeshed...

I'm not on this list; please keep me in the Reply chain.

H
Permalink | Reply | 3 comments |
headers
Simon J. Gerraty | 17 Jan 2003 06:55

Re: (b)make enhancement

Harlan Stenn <Harlan.Stenn <at> pfcs.com> writes:
>One thing that would really help me is .error (which is in FreeBSD) as well
>as .warn (which is not).

>I have working patches to the code and man page, and Simon tells me I should
>float the idea here first.

We have a couple of Simon's, he means me ;-)

I have no objection to .error and although I'm not a great fan of warnings
(if its worth saying - its usually worth an error. ;-) I don't have
any objection to haveing .warn (.warning ?) too, but since any change
to make has the potential to hose someone, want to see if there is 
support from other quarters before looking at cleanup up and adding this 
feature.

Thanks
--sjg
Permalink | Reply | 0 comments |
headers
Hubert Feyrer | 17 Jan 2003 12:47
Picon

Re: (b)make enhancement

On Fri, 17 Jan 2003, Harlan Stenn wrote:
> One thing that would really help me is .error (which is in FreeBSD) as well
> as .warn (which is not).
>
> I have working patches to the code and man page, and Simon tells me I should
> float the idea here first.

Well, so let it float! :)

 - Hubert

--

-- 
Want to get a clue on IPv6 but don't know where to start? Try this:
* Basics -> http://www.onlamp.com/pub/a/onlamp/2001/05/24/ipv6_tutorial.html
* Setup  -> http://www.onlamp.com/pub/a/onlamp/2001/06/01/ipv6_tutorial.html
Of course with your #1 IPv6 ready operating system -> http://www.NetBSD.org/
Permalink | Reply | 1 comment |
headers
Harlan Stenn | 17 Jan 2003 20:57
X-Face
Favicon

Re: (b)make enhancement

Basically, I added:

 .error message

and

 .warn message

along side .include and .undef .

Here's a more detailed explanation:

--- make.1.orig	Thu Jan 16 20:33:26 2003
+++ make.1	Thu Jan 16 20:56:26 2003
 <at>  <at>  -806,18 +806,20  <at>  <at> 
 .Ar cmd
 to the variable.
 .El
-.Sh INCLUDE STATEMENTS, CONDITIONALS AND FOR LOOPS
-Makefile inclusion, conditional structures and for loops  reminiscent
+.Sh DIRECTIVE, CONDITIONALS AND FOR LOOPS
+Directives, conditional structures and for loops reminiscent
 of the C programming language are provided in
 .Nm "" .
 All such structures are identified by a line beginning with a single
 dot
 .Pq Ql \&.
 character.
-Files are included with either
-.Cm \&.include Aq Ar file
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon J. Gerraty | 20 Jan 2003 19:00

-current: creating bogus base.tgz etc

I build -current (as of yesterday) to build a diskless env for my
ss20 - so I can leave 1.6 on the disk.

The build completed ok (UNPRIV), but when it came to building the
sets:

DESTDIR=/var/obj/NetBSD/current/sparc/destdir  MACHINE=sparc \
 MACHINE_ARCH=sparc  \
 MAKE=/NetBSD/tools/current/NetBSD-1.6_STABLE-i386/bin/nbmake \
 MTREE=/NetBSD/tools/current/NetBSD-1.6_STABLE-i386/bin/nbmtree \
 PAX=/NetBSD/tools/current/NetBSD-1.6_STABLE-i386/bin/nbpax \
 sh /g/NetBSD/current/src/distrib/sets/maketars \
 -d /var/obj/NetBSD/current/sparc/destdir  \
 -M /var/obj/NetBSD/current/sparc/destdir/METALOG \
 -N /g/NetBSD/current/src/etc  \
 -t /var/obj/NetBSD/current/sparc/release/sparc/binary/sets 
Parsing /var/obj/NetBSD/current/sparc/destdir/METALOG
nbmtree: ./var/obj: No such file or directory
nbmtree: failed at line 854 of the specification
Creating base.tgz
Creating comp.tgz
...

each of base.tgz etc were only 20 bytes.  METALOG entries start
with:

./var/obj/NetBSD/current/sparc/destdir type=dir mode=0755 \
	uname=root gname=wheel tags=base_pkg
./var/obj/NetBSD/current/sparc/destdir/sys type=link \
	mode=0755 link=usr/src/sys uname=root gname=wheel tags=base_pkg
(Continue reading)

Permalink | Reply | 0 comments |

Gmane