Solved: Problems building en-openoffice.org-GB-3.1.1 from ports
On Saturday 02 January 2010, Mike Clarke wrote:
After successfully moving from 6.4 to 8.0 by doing a clean install
I've embarked on the task of rebuilding OpenOffice from ports :-(
I'm getting a confusing error in the config stage:
=== Configuring for en-openoffice.org-GB-3.1.1
snip
checking for
gperf...
/backup/tmp/ports/work/usr/ports/editors/openoffice.org-3/work/OOO310
_m19/solenv/bin/gperf checking gperf version... /libexec/ld-elf.so.1:
Shared
object libstdc++.so.5 not found, required by gperf
test: : bad number
configure: error: too old, you need at least 3.0.0
=== Script configure failed unexpectedly.
and on Sunday 03 January 2010, Matthew Seaman wrote:
Mike Clarke wrote:
After pondering a bit more over this problem I think I know where
the 6.4 stuff may have come from. After I built the base system I
copied various useful files from /root on the 6.4 system,
including /root/.cshrc which contained a line setting PACKAGESITE
to
ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ports/i386/packages-6.4-relea
se/All/ and it's quite possible that I ran portinstall -P for some
ports before I got round to changing this to point to packages-8.
Yep. This would stick a fairly hefty spanner in the works.
Considering the vast number of files in /usr/local/bin with links
to missing libraries I think my best approach now will be to
deinstall ALL my ports and reinstall them again from scratch after
deleting everything in /usr/ports/packages and checking that all
directories in /usr/local (except etc) have been emptied.
This also is a good move. Don't forget to treat /compat/linux
similarly to /usr/local if you have any linux stuff installed --
there have been a lot of changes to the linuxulator newly available
in 8.0 which you really want if you're going to run linux stuff under
emulation. If you strip out /compat/linux completely, then under 8.0
you'll get the latest linux-base-f10 by default when you re-install.
When reinstalling ported software, it's a good idea to adopt the
following strategies:
* Install whatever ports management software you prefer
(portupgrade(1), portmaster(1)) pretty much straight away -- you'll
need this to build everything.
* Look at the list of installed packages on your 6.4 install, and
pick out the packages that are your end-use applications. These will
mostly be leaf packages, but not always.
* You only need to reinstall just those packages -- everything
else should be installed automatically as dependencies. This will
help you avoid installing and outdated build dependencies or
otherwise orphaned packages which otherwise tend to accumulate on an
actively updated system. * For the end-use packages you choose, run
'make config-recursive' before you start building anything to ensure
you've selected all the required options. Or use portmanager(1)
which runs you through the config stage first of all. You need to be
a bit careful doing this, as toggling an option in a port can
radically change its dependency list, and may bring new sets of
options into play. To resolve that, you'll need to re-run 'make
config-recursive' until it no longer prompts you to make any OPTIONS
settings. [There's a PR to fix this behaviour in the works, but it
hasn't been committed yet.]
* Where there are ports that have compilation flags or knobs that
aren't controlled through OPTIONS dialogues, then be sure to record
any non- default settings in /etc/make.conf. You can use a construct
like this to only apply settings to specific ports:
.if ${.CURDIR:M*/mail/dkim-milter}
WITH_LIBDKIM_INSTALL= yes
WITH_LIBDKIM_SHARED=yes
WITH_VERIFY_DOMAINKEYS= yes
WITH_STATS= yes
WITH_DNS_UPGRADE= yes
.endif
Well known KNOBS should be set globally where you aren't using
the default setting, eg:
WITH_OPENSSL_PORT= yes
WITH_BDB_VER= 47
WITH_MYSQL_VER= 51
WITH_OPENLDAP_VER= 24
WANT_OPENLDAP_SASL= yes
WITH_GECKO= libxul
WITH_APACHE2= yes
APACHE_PORT=www/apache22
WITH_MODPERL2= yes
PERL_VERSION= 5.10.1
Again, changing these settings can affect the dependency tree
and potentially bring new sets of OPTIONS into play, so test
repeatedly with 'make config-recursive'
* It's a good idea to run 'make fetch-recursive' or 'portinstall
-RF ...' or 'portmaster -F ...' after sorting out configuration to
download any distfiles before trying to build everything, as this is
another place where a big build session can blow up while you aren't
looking. It's not mandatory though.
* Once everything is configured nicely, it should be possible to
just run a massive portupgrade(1) or portmaster(1) session unattended
to build and install everything, without finding that 10
Re: Problems building en-openoffice.org-GB-3.1.1 from ports
On Sunday 03 January 2010, Matthew Seaman wrote: Mike Clarke wrote: After pondering a bit more over this problem I think I know where the 6.4 stuff may have come from. After I built the base system I copied various useful files from /root on the 6.4 system, including /root/.cshrc which contained a line setting PACKAGESITE to ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ports/i386/packages-6.4-relea se/All/ and it's quite possible that I ran portinstall -P for some ports before I got round to changing this to point to packages-8. Yep. This would stick a fairly hefty spanner in the works. It certainly made quite a mess but it's surprising how well the system has been running with all this damage. Thanks for your comments and suggestions regarding the rebuilding process. Although the procedure I had in mind was similar some of your suggestions hadn't occurred to me and are much appreciated, I would almost certainly have overlooked /compat/linux and the need to re-run config-recursive. I've copied my system over to a spare PC so I can rebuild all the ports on the original machine without loosing access to a (sort of) working system. All the ports have been deinstalled from the original machine and I will now start work on re-installing the ports. Rather than run a single massive upgrade job I'll follow my normal practise of getting xorg and my nvidia driver working first then install the rest in a big batch. -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems building en-openoffice.org-GB-3.1.1 from ports
On Saturday 02 January 2010, Mike Clarke wrote: ... and the build of OpenOffice ran through the configure stage without any problems so I'm keeping my fingers crossed that it'll still be compiling tomorrow. Well it went a bit further but failed with the following: --- Checking DLL ../unxfbsdi.pro/lib/check_i18npool.uno.so ...-rwxr-xr-x 1 root wheel 2897131 Jan 2 23:53 ../unxfbsdi.pro/lib/i18npool.uno.so Running processes: 0 deliver -- version: 266154 Module 'i18npool' delivered successfully. 29 files copied, 5 files unchanged 1 module(s): cppunit need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /backup/tmp/usr/ports/editors/openoffice.org-3/work/OOO310_m19/cppunit Attention: if you build and deliver the above module(s) you may prolongue your the build issuing command build --from cppunit rmdir /tmp/17668 *** Error code 1 Stop in /usr/ports/editors/openoffice.org-3. --- After pondering a bit more over this problem I think I know where the 6.4 stuff may have come from. After I built the base system I copied various useful files from /root on the 6.4 system, including /root/.cshrc which contained a line setting PACKAGESITE to ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ports/i386/packages-6.4-release/All/ and it's quite possible that I ran portinstall -P for some ports before I got round to changing this to point to packages-8. Considering the vast number of files in /usr/local/bin with links to missing libraries I think my best approach now will be to deinstall ALL my ports and reinstall them again from scratch after deleting everything in /usr/ports/packages and checking that all directories in /usr/local (except etc) have been emptied. -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems building en-openoffice.org-GB-3.1.1 from ports
Mike Clarke wrote:
After pondering a bit more over this problem I think I know where the
6.4 stuff may have come from. After I built the base system I copied
various useful files from /root on the 6.4 system,
including /root/.cshrc which contained a line setting PACKAGESITE to
ftp://ftp2.uk.freebsd.org/pub/FreeBSD/ports/i386/packages-6.4-release/All/
and it's quite possible that I ran portinstall -P for some ports before
I got round to changing this to point to packages-8.
Yep. This would stick a fairly hefty spanner in the works.
Considering the vast number of files in /usr/local/bin with links to
missing libraries I think my best approach now will be to deinstall ALL
my ports and reinstall them again from scratch after deleting
everything in /usr/ports/packages and checking that all directories
in /usr/local (except etc) have been emptied.
This also is a good move. Don't forget to treat /compat/linux similarly
to /usr/local if you have any linux stuff installed -- there have been a
lot of changes to the linuxulator newly available in 8.0 which you really
want if you're going to run linux stuff under emulation. If you strip out
/compat/linux completely, then under 8.0 you'll get the latest linux-base-f10
by default when you re-install.
When reinstalling ported software, it's a good idea to adopt the following
strategies:
* Install whatever ports management software you prefer (portupgrade(1),
portmaster(1)) pretty much straight away -- you'll need this to build
everything.
* Look at the list of installed packages on your 6.4 install, and pick
out the packages that are your end-use applications. These will mostly
be leaf packages, but not always.
* You only need to reinstall just those packages -- everything else should
be installed automatically as dependencies. This will help you avoid
installing and outdated build dependencies or otherwise orphaned packages
which otherwise tend to accumulate on an actively updated system.
* For the end-use packages you choose, run 'make config-recursive' before
you start building anything to ensure you've selected all the required
options. Or use portmanager(1) which runs you through the config stage
first of all. You need to be a bit careful doing this, as toggling an
option in a port can radically change its dependency list, and may bring
new sets of options into play. To resolve that, you'll need to re-run
'make config-recursive' until it no longer prompts you to make any
OPTIONS settings. [There's a PR to fix this behaviour in the works, but
it hasn't been committed yet.]
* Where there are ports that have compilation flags or knobs that aren't
controlled through OPTIONS dialogues, then be sure to record any non-
default settings in /etc/make.conf. You can use a construct like this
to only apply settings to specific ports:
.if ${.CURDIR:M*/mail/dkim-milter}
WITH_LIBDKIM_INSTALL= yes
WITH_LIBDKIM_SHARED=yes
WITH_VERIFY_DOMAINKEYS= yes
WITH_STATS= yes
WITH_DNS_UPGRADE= yes
.endif
Well known KNOBS should be set globally where you aren't using the
default setting, eg:
WITH_OPENSSL_PORT= yes
WITH_BDB_VER= 47
WITH_MYSQL_VER= 51
WITH_OPENLDAP_VER= 24
WANT_OPENLDAP_SASL= yes
WITH_GECKO= libxul
WITH_APACHE2= yes
APACHE_PORT=www/apache22
WITH_MODPERL2= yes
PERL_VERSION= 5.10.1
Again, changing these settings can affect the dependency tree and
potentially bring new sets of OPTIONS into play, so test repeatedly
with 'make config-recursive'
* It's a good idea to run 'make fetch-recursive' or 'portinstall -RF ...'
or 'portmaster -F ...' after sorting out configuration to download any
distfiles before trying to build everything, as this is another place
where a big build session can blow up while you aren't looking. It's
not mandatory though.
* Once everything is configured nicely, it should be possible to just
run a massive portupgrade(1) or portmaster(1) session unattended to
build and install everything, without finding that 10 minutes after
you went home the build stopped at an OPTIONS screen and sat there all
night... In fact, it is well worth temporarily defining BATCH in
make.conf or the environment to just accept the defaults for anything
not yet configured during a big build job like this. (But not otherwise.
BATCH isn't a good idea for an incremental upgrade IMHO.)
If you follow these guidelines when installing the system you should find
that not only does it make your initial install run smoothly, but it sets
you up well for managing updates to the installed system in the future.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Re: Problems building en-openoffice.org-GB-3.1.1 from ports
On Sun, 3 Jan 2010, Mike Clarke wrote: On Saturday 02 January 2010, Mike Clarke wrote: ... and the build of OpenOffice ran through the configure stage without any problems so I'm keeping my fingers crossed that it'll still be compiling tomorrow. Well it went a bit further but failed with the following: --- Checking DLL ../unxfbsdi.pro/lib/check_i18npool.uno.so ...-rwxr-xr-x 1 root wheel 2897131 Jan 2 23:53 ../unxfbsdi.pro/lib/i18npool.uno.so Running processes: 0 deliver -- version: 266154 Module 'i18npool' delivered successfully. 29 files copied, 5 files unchanged 1 module(s): cppunit need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /backup/tmp/usr/ports/editors/openoffice.org-3/work/OOO310_m19/cppunit If the FreeBSD port of devel/cppunit is installed, the openoffice build errors out when that conflicts with its own internal cppunit. Or it did a while back, anyway. -Warren Block * Rapid City, South Dakota USA ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Problems building en-openoffice.org-GB-3.1.1 from ports
After successfully moving from 6.4 to 8.0 by doing a clean install I've embarked on the task of rebuilding OpenOffice from ports :-( I'm getting a confusing error in the config stage: === Configuring for en-openoffice.org-GB-3.1.1 snip checking for gperf... /backup/tmp/ports/work/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solenv/bin/gperf checking gperf version... /libexec/ld-elf.so.1: Shared object libstdc++.so.5 not found, required by gperf test: : bad number configure: error: too old, you need at least 3.0.0 === Script configure failed unexpectedly. True enough I don't have a native libstdc++.so.5 . /usr/local/lib/gcc/i386-portbld-freebsd6.4/3.4.6/libstdc++.so.6 /usr/local/lib/compat/libstdc++.so.4 /usr/lib/libstdc++.so.6 /usr/compat/linux/usr/lib/libstdc++.so.5.0.7 /usr/compat/linux/usr/lib/libstdc++.so.6.0.10 The only similar problem I could find on Google was a post to the freebsd-ports list 2 years ago where someone had a problem with a pre-built package of OpenOffice except that it required libstdc++.so.6 and he had libstdc++.so.5. So I'm puzzled why now, 2 years later, OpenOffice needs an older version of libstdc++.so. As an experiment I added a link for libstdc++.so.5 in /usr/lib and this stopped the message about libstdc++.so.5 but produced a new one about libm.so.4 not being found, and still complained about gperf being too old. I've now put this task on the back burner while I ask for advice here instead of digging an even deeper hole for myself. I assume that at least 3.0.0 refers to the version of gperf but I already have gperf-3.0.3. Does this look like a bug or have I done something wrong? -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Problems building en-openoffice.org-GB-3.1.1 from ports
Mike Clarke wrote: After successfully moving from 6.4 to 8.0 by doing a clean install I've embarked on the task of rebuilding OpenOffice from ports :-( I'm getting a confusing error in the config stage: === Configuring for en-openoffice.org-GB-3.1.1 snip checking for gperf... /backup/tmp/ports/work/usr/ports/editors/openoffice.org-3/work/OOO310_m19/solenv/bin/gperf checking gperf version... /libexec/ld-elf.so.1: Shared object libstdc++.so.5 not found, required by gperf test: : bad number configure: error: too old, you need at least 3.0.0 === Script configure failed unexpectedly. gperf comes with the base system as well: % /usr/bin/gperf --version GNU gperf 2.7.2 but it is certainly possible to build OOo under FreeBSD 8.0 -- it will install the ports version of gperf as a build dependency. True enough I don't have a native libstdc++.so.5 . /usr/local/lib/gcc/i386-portbld-freebsd6.4/3.4.6/libstdc++.so.6 ^^^ Looks like something that was installed under FreeBSD 6.4. Dunno what in the up-to-date ports tree would need gcc-3.4 since the base system is now up to gcc-4.2, and that's quite capable of compiling OOo. /usr/local/lib/compat/libstdc++.so.4 ^^^ This is from the compat6x port /usr/lib/libstdc++.so.6 ^^^ the version from 8.0 base system libstdc++.so.5 would be part of a 7.x base system, but as you've gone to 8.0 by doing a clean install, nothing should be referencing that version. What does 'ldd /usr/local/bin/gperf' tell you? At a guess you haven't followed the often repeated advice to reinstall /all/ your ports when you do a major version upgrade. That means recompile from source in correct dependency order, or install pkgs compiled under 8.0. Yes, it's tedious. Yes, it consumes a lot of CPU cycles. But now you understand why this is good advice... Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Problems building en-openoffice.org-GB-3.1.1 from ports
On Saturday 02 January 2010, Matthew Seaman wrote: /usr/local/lib/gcc/i386-portbld-freebsd6.4/3.4.6/libstdc++.so.6 ^^^ Looks like something that was installed under FreeBSD 6.4. But I installed 8.0 on an empty slice so there wouldn't have been any 6.4 stuff still lying around. Dunno what in the up-to-date ports tree would need gcc-3.4 since the base system is now up to gcc-4.2, and that's quite capable of compiling OOo. Yes gcc-3.4 pulled that in but I don't know how gcc-3.4 got there, nothing seems to depend on it. curlew:/home/mike% pkg_info -Rr gcc-3.4.6_3,1 Information for gcc-3.4.6_3,1: Depends on: Dependency: libiconv-1.13.1 /usr/local/lib/compat/libstdc++.so.4 ^^^ This is from the compat6x port It's actually from compat5x which I need for nvidia-driver-96.43.13. For some obscure reason that I was never able to solve I could never get X to work with my GeForce 6150 chipset on FreeBSD 6.4 with any of the more recent Nvidia drivers so I assumed I'd still need to use this version. Perhaps it's time to see if the latest driver will work for me with 8.0 so that I can get rid of compat5x . /usr/lib/libstdc++.so.6 ^^^ the version from 8.0 base system libstdc++.so.5 would be part of a 7.x base system, but as you've gone to 8.0 by doing a clean install, nothing should be referencing that version. What does 'ldd /usr/local/bin/gperf' tell you? curlew:/home/mike% ldd /usr/local/bin/gperf /usr/local/bin/gperf: libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x33ca) libm.so.4 = not found (0x0) libc.so.6 = not found (0x0) libm.so.5 = /lib/libm.so.5 (0x33d94000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x33dae000) libc.so.7 = /lib/libc.so.7 (0x33db9000) The two not found lines look a bit worrying, perhaps I'd better rebuild gperf. At a guess you haven't followed the often repeated advice to reinstall /all/ your ports when you do a major version upgrade. That means recompile from source in correct dependency order, or install pkgs compiled under 8.0. Yes, it's tedious. Yes, it consumes a lot of CPU cycles. But now you understand why this is good advice... It certainly looks like that but it's not the case here. Being aware of the time and disruption needed to rebuild everything I decided not to upgrade the existing 6.4 system but to build 8.0 from scratch on a spare slice. That way I could install the ports as and when time permitted and still be able to reboot back into a fully functional system when needed for production work. I've just now run portupgrade -f gperf and things are looking a bit more promising. ldd /usr/local/bin/gperf now shows: /usr/local/bin/gperf: libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x33ca2000) libm.so.5 = /lib/libm.so.5 (0x33d96000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x33db) libc.so.7 = /lib/libc.so.7 (0x33dbb000) ... and the build of OpenOffice ran through the configure stage without any problems so I'm keeping my fingers crossed that it'll still be compiling tomorrow. Even if OpenOffice builds OK I think I've still got problems to solve. A trawl through /usr/local/bin shows that there's lots of program with links to missing libraries. I suspect I'm going to have to do portupgrade -af and rebuild all the ports. -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
