devel/gmake-lite: fails on CURRENT r 268535 to build: @itemx must follow @item

Mon Jul 14 20:04:02 UTC 2014

Am Mon, 14 Jul 2014 09:24:40 -0700
Kevin Oberman <rkoberman at gmail.com> schrieb:

> On Sun, Jul 13, 2014 at 11:51 PM, O. Hartmann <ohartman at zedat.fu-berlin.de>
> wrote:
> 
> > Am Sun, 13 Jul 2014 22:16:39 -0500
> > Bryan Drewery <bdrewery at FreeBSD.org> schrieb:
> >
> > > On 7/11/2014 7:19 PM, Baptiste Daroussin wrote:
> > > > On Fri, Jul 11, 2014 at 10:53:10PM +0200, O. Hartmann wrote:
> > > >>
> > > >> On FreeBSD 11.0-CURRENT #2 r268535: Fri Jul 11 22:09:39 CEST 2014
> > amd64 the port
> > > >> devel/gmake-lite fails to build with the following error, shown
> > below. The port is
> > > >> prerequisite and needed for lang/gcc4[89] which has been updated
> > recently.
> > > >>
> > > >> The box failing has recently been "cleaned up" via make
> > delete-old-libs in /usr/src.
> > > >> Is there anything I can do or fix?
> > > >>
> > > >> Please CC me.
> > > >>
> > > >> oh
> > > >
> > > > Can you provide the config.log that goes with the failure?
> > > >
> > > > because I'm not able to reproduce for now with the same env. as you
> > describe.
> > > >
> > > > regards,
> > > > Bapt
> > > >
> > >
> > > Check on package23, it just happened there.
> > >
> > >
> >
> > I fugured out that my systems are "polluted" by orphaned libraries and
> > binaries. I guess
> > pkg and/or portmaster's pkg-distfiles isn't always working properly or it
> > is due to the
> > fact my system's OS is a moving objekct, always sliding from one CURRENT
> > to the next.
> >
> > So, this said, I removed a bunch of really outdated binaries (find -ctime
> > +100w). After
> > this done, the port has been installed correctly.
> >
> > At the very moment I run sysutils/libchk and it reports a lot of strange
> > things.
> >
> > Is there a way to clean-up those lost and unnecessary libraries, binaries
> > and other files
> > or remnants in general without installing the system from scratch?
> > Deleting all ports and
> > installing them again is no option, the box in question is a little bit
> > outdated and slow
> > and is needed (i can not wait 72 hours to finish ~1300 ports).
> >
> > Thanks for looking into this.
> >
> > Kind regards,
> > Oliver
> >
> 
> Hopefully someone has a better plan, but what I have done in the past is to
> re-build all ports, but in an alternate location on a USB disk
> (/media/disk1) and saving packages of all of them
> 
> Follow the directions in the EXAMPLES in portmaster(8) to re-build all
> ports. Afterthe first step, scan over the list and delete orphaned
> dependencies. Remember that only ports on which no other port is dependent
> should be listed, so if you see a port listed that you are not using
> internally, it can be deleted. Continue following the procedure described
> in portmaster(8), but define LOCALBASE to point to a directory on the USB
> drive and add '-g' to save packages for all ports so that  You now have a
> poor-man's repository. Delete all ports, clean up /usr/local being careful
> to not overwrite customized files in /usr/local/etc, and install all of the
> ports from the packages you just built.
> 
> You will still have downtime, but far, far less than the time to build
> everything as the system remains up and available during the time required
> for the build.

Hello Kevin.
Thank you very much for this nice hint.

Since I experience and experienced starnge things on that particular box, even some kind
of strange bit flips but no faulty memory/hardware so far, I started looking around for
orphaned/outdated libraries in the main tree. I found lots of libs located in /usr/lib
with dates that predates today (last time I updated and installed world was today!) and
even /lib seems to have some "forgotten" lib:

212037 -r--r--r--   1 root  wheel  -      11K Jul  9 11:04 libsbuf.so.6
212038 -r--r--r--   1 root  wheel  -      11K Jul 14 11:43 libsbuf.so.7

System is FreeBSD 11.0-CURRENT #4 r268564: Sat Jul 12 09:08:15 CEST 2014 amd64 and I see
this on ALL CURRENT of the same date (today) I've running. "make delete-old-libs" didn't
kill the libsbuf.so.6.

Even more weird is /usr/lib. There are lots of libs dated to May or even April, like the
ar archives, examples here:

[...]
802829 lrwxr-xr-x   1 root  wheel  -      12B Jul 14 19:07 libwrap.so@ -> libwrap.so.6
802828 -r--r--r--   1 root  wheel  -      37K Jul 14 19:07 libwrap.so.6
803736 -r--r--r--   1 root  wheel  -      74K May 13 12:33 libwrap_p.a
803741 -r--r--r--   1 root  wheel  -     3.3K May 13 12:33 liby.a
803746 -r--r--r--   1 root  wheel  -     3.5K May 13 12:33 liby_p.a
803114 -r--r--r--   1 root  wheel  -      37K May 13 12:33 libypclnt.a
802833 lrwxr-xr-x   1 root  wheel  -      14B Jul 14 19:07 libypclnt.so@ -> libypclnt.so.4
802832 -r--r--r--   1 root  wheel  -      19K Jul 14 19:07 libypclnt.so.4
803118 -r--r--r--   1 root  wheel  -      38K May 13 12:33 libypclnt_p.a
803749 -r--r--r--   1 root  wheel  -     123K May 13 12:33 libz.a
802834 lrwxr-xr-x   1 root  wheel  -      14B Jul 14 19:07 libz.so@ -> /lib/libz.so.6
803750 -r--r--r--   1 root  wheel  -     129K May 13 12:33 libz_p.a
803452 -r--r--r--   1 root  wheel  -     497K Jul 11 17:12 libzfs.a
802901 lrwxr-xr-x   1 root  wheel  -      16B Jul 14 19:08 libzfs.so@ -> /lib/libzfs.so.2
803430 -r--r--r--   1 root  wheel  -      21K Jul  2 20:44 libzfs_core.a
802900 lrwxr-xr-x   1 root  wheel  -      21B Jul 14 19:08 libzfs_core.so@
-> /lib/libzfs_core.so.2 803431 -r--r--r--   1 root  wheel  -      22K Jul  2 20:44
libzfs_core_p.a 803453 -r--r--r--   1 root  wheel  -     659K Jul 11 17:12 libzfs_p.a
803456 -r--r--r--   1 root  wheel  -     8.8M Jul 11 17:12 libzpool.a
[...]

or the bunch or PAM archives, which dates to 

[...]
803229 -r--r--r--   1 root  wheel  -     308K Jul  2 20:44 libpam.a
802774 lrwxr-xr-x   1 root  wheel  -      11B Jul 14 19:07 libpam.so@ -> libpam.so.5
802773 -r--r--r--   1 root  wheel  -      52K Jul 14 19:07 libpam.so.5
803144 -r--r--r--   1 root  wheel  -     4.3K Apr 24 16:21 libpam_chroot.a
803145 -r--r--r--   1 root  wheel  -     4.4K Apr 24 16:21 libpam_chroot_p.a
803136 -r--r--r--   1 root  wheel  -     2.9K Apr 24 16:21 libpam_deny.a
803146 -r--r--r--   1 root  wheel  -     3.1K Apr 24 16:21 libpam_deny_p.a
803151 -r--r--r--   1 root  wheel  -     3.9K Apr 24 16:21 libpam_echo.a
803152 -r--r--r--   1 root  wheel  -     4.4K Apr 24 16:21 libpam_echo_p.a
803153 -r--r--r--   1 root  wheel  -      12K Apr 24 16:21 libpam_exec.a
803158 -r--r--r--   1 root  wheel  -      12K Apr 24 16:21 libpam_exec_p.a
803159 -r--r--r--   1 root  wheel  -     4.2K Apr 24 16:21 libpam_ftpusers.a
803165 -r--r--r--   1 root  wheel  -     4.3K Apr 24 16:21 libpam_ftpusers_p.a

[...]

I do not know how to deal with those since I think there is something fishy. I thought
all libraries get written anew when performing installworld.

Oliver
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140714/7dcdc139/attachment.sig>