Re: trouble compiling some ports

2007-07-22 Thread Christian Baer
On Sun, 22 Jul 2007 15:47:08 -0500 Derek Ragona wrote:

I am grateful for your feedback, but please try to avoid fullquotes and
only quote the part you are directly refering to. That makes things a
lot shorter and easier to read. And avoids long scrolling. :-)

> I had similar problems on one server that had an old ports tree then 
> updated ports.  I ended up having to completely delete and re-download the 
> entire ports tree, and manually remove portupgrade and portmanager and 
> reinstall them.

Well, in this case the ports *were* completely fresh from the cvs-tree.
I missed installing them via ftp and so csup created them for me. I have
however until today never had any problems with updating ports before.

Regards
Chris
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: trouble compiling some ports

2007-07-22 Thread Derek Ragona

At 02:06 PM 7/22/2007, Christian Baer wrote:

Hello Folks!

Currently I am setting up a new computer (Sun U60) with FreeBSD and I am
in serious guano. :-/

I am currently running 6.2-p6, of course with the ports up to date.
Normally the ports would not be the install method of choice since the
processors of this machine are relatively slow and compiling of slightly
bigger projects seems to take forever - especially since most ports
won't compile with multipal jobs. However, probably because of the
fact that all UltraSPARC CPUs that FreeBSD supports are this slow and
AFAIK cross-plattform-compiling is not supported (yet), many of the
packages are really ancient. So if you want up to date software, you
have to use the ports.

First I tried to install portupgrade. That however failed with an error
message that lets me think, there is still some confusion because this
port was moved from sysutils/ to ports-mgmt/.[1,7] This suspicion is
hardened by the fact that ruby won't compile when it is built as a
dependency of portupgrade, however it *does* compile and install
without any complications if this is done directly from the
/usr/ports/lang/ruby18/ directory.

Well, since that didn't work I decided to get busy on the MTA. I don't
much like Sendmail (although I had some thoughts about getting re-
aquainted) and Postfix is a little more what I want. Postfix requires
Perl 5.8 to work and if that isn't installed, the Postfix port does that
for me. Because I like to at least look at the options of each port
before I build and install anything, I decided to install Perl 5.8 "on
foot" (from the port of course). But that too refused to work. The build
stops with an error code 1 while still saying that everything is ok[2].

To verify what happened, the port offers a "make test" which I ran.
While this is running it spits out several messages like this one:

lib/Test/Simple/t/threads.skipping test on this platform

where I have to admit that I don't understand why these specific test do
not apply to my plattform. There are some that I understand (like some
tests for Win32), but not all of them. Well I guess the programmer knew
what he/she was doing and left it at that.

make test also spits out three error messages[3,4,5] which I haven't
included in the correct order, I'm afraid. The end of the test script
shows an error message[6] which doesn't really make me feel confident
about installing what I've just built.

Note #1:
You may find that in the messages shown below, Perl was compiled with
the -mcpu option which tends to break some ports (or even make
buildworld). I know about this and have tried several very conservative
options, down to only "-O -pipe". I have also tried not only p6 but also
the current -STABLE, compiled with different compiler-options - which I
might say is *very* ball-busting on such a slow machine.

Note #2:
Someone in a German newsgroup told me that this problem (Perl won't
compile) seems to apply to AMD64 as well. This would *really* surprise
me as Perl is widely used and I didn't find any reports of this problem
anywhere else.

Note #3:
The error message noted in [3] seems a bit more that a coincidence:
 returned,
1000 expected.
There were thoughts about big-/little-endian (SPARC is big-endian)
problems but also about a bug in gcc's data-types.

Can anyone help?

Regards,
Chris


[1] last lines from portupgrade's build
/usr/local/bin/ruby18 -p  -e 'sub %r:/usr/local:, "/usr/local"'
ports.rb > .build/ports.rb
/usr/local/bin/ruby18 -wc portsdb.rb
Syntax OK
/usr/local/bin/ruby18 -p  -e 'sub %r:/usr/local:, "/usr/local"'
portsdb.rb > .build/portsdb.rb
===> man (all)
Warning: Object directory not changed from original
/usr/ports/ports-mgmt/portupgrade/work/pkgtools-2.3.1/man
gzip -cn pkg_deinstall.1 > pkg_deinstall.1.gz
gzip -cn pkg_fetch.1 > pkg_fetch.1.gz
gzip -cn pkg_glob.1 > pkg_glob.1.gz
gzip -cn pkg_sort.1 > pkg_sort.1.gz
gzip -cn pkgdb.1 > pkgdb.1.gz
gzip -cn portcvsweb.1 > portcvsweb.1.gz
gzip -cn portsclean.1 > portsclean.1.gz
gzip -cn portsdb.1 > portsdb.1.gz
gzip -cn portupgrade.1 > portupgrade.1.gz
gzip -cn portversion.1 > portversion.1.gz
gzip -cn pkgtools.conf.5 > pkgtools.conf.5.gz
===> misc (all)
===> misc/bash (all)
Warning: Object directory not changed from original
/usr/ports/ports-mgmt/portupgrade/work/pkgtools-2.3.1/misc/bash
===> misc/tcsh (all)
Warning: Object directory not changed from original
/usr/ports/ports-mgmt/portupgrade/work/pkgtools-2.3.1/misc/tcsh
===> misc/zsh (all)
Warning: Object directory not changed from original
/usr/ports/ports-mgmt/portupgrade/work/pkgtools-2.3.1/misc/zsh



[2] End of the Perl 5.8 build
Making threads::shared (dynamic)
Writing Makefile for threads::shared
cp shared.pm ../../../lib/threads/shared.pm
../../../miniperl "-I../../../lib" "-I../../../lib"
../../../lib/ExtUtils/xsubpp  -typemap ../../