[head tinderbox] failure on powerpc64/powerpc
TB --- 2012-02-22 05:04:07 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-02-22 05:04:07 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2012-02-22 05:04:07 - cleaning the object tree TB --- 2012-02-22 05:04:07 - cvsupping the source tree TB --- 2012-02-22 05:04:07 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2012-02-22 05:04:45 - building world TB --- 2012-02-22 05:04:45 - CROSS_BUILD_TESTING=YES TB --- 2012-02-22 05:04:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-22 05:04:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-22 05:04:45 - SRCCONF=/dev/null TB --- 2012-02-22 05:04:45 - TARGET=powerpc TB --- 2012-02-22 05:04:45 - TARGET_ARCH=powerpc64 TB --- 2012-02-22 05:04:45 - TZ=UTC TB --- 2012-02-22 05:04:45 - __MAKE_CONF=/dev/null TB --- 2012-02-22 05:04:45 - cd /src TB --- 2012-02-22 05:04:45 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 22 05:04:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Feb 22 07:32:21 UTC 2012 TB --- 2012-02-22 07:32:21 - generating LINT kernel config TB --- 2012-02-22 07:32:21 - cd /src/sys/powerpc/conf TB --- 2012-02-22 07:32:21 - /usr/bin/make -B LINT TB --- 2012-02-22 07:32:21 - cd /src/sys/powerpc/conf TB --- 2012-02-22 07:32:21 - /usr/sbin/config -m LINT TB --- 2012-02-22 07:32:21 - building LINT kernel TB --- 2012-02-22 07:32:21 - CROSS_BUILD_TESTING=YES TB --- 2012-02-22 07:32:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-22 07:32:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-22 07:32:21 - SRCCONF=/dev/null TB --- 2012-02-22 07:32:21 - TARGET=powerpc TB --- 2012-02-22 07:32:21 - TARGET_ARCH=powerpc64 TB --- 2012-02-22 07:32:21 - TZ=UTC TB --- 2012-02-22 07:32:21 - __MAKE_CONF=/dev/null TB --- 2012-02-22 07:32:21 - cd /src TB --- 2012-02-22 07:32:21 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 22 07:32:21 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Wed Feb 22 07:53:05 UTC 2012 TB --- 2012-02-22 07:53:05 - cd /src/sys/powerpc/conf TB --- 2012-02-22 07:53:05 - /usr/sbin/config -m GENERIC TB --- 2012-02-22 07:53:05 - skipping GENERIC kernel TB --- 2012-02-22 07:53:05 - cd /src/sys/powerpc/conf TB --- 2012-02-22 07:53:05 - /usr/sbin/config -m GENERIC64 TB --- 2012-02-22 07:53:05 - building GENERIC64 kernel TB --- 2012-02-22 07:53:05 - CROSS_BUILD_TESTING=YES TB --- 2012-02-22 07:53:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-22 07:53:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-22 07:53:05 - SRCCONF=/dev/null TB --- 2012-02-22 07:53:05 - TARGET=powerpc TB --- 2012-02-22 07:53:05 - TARGET_ARCH=powerpc64 TB --- 2012-02-22 07:53:05 - TZ=UTC TB --- 2012-02-22 07:53:05 - __MAKE_CONF=/dev/null TB --- 2012-02-22 07:53:05 - cd /src TB --- 2012-02-22 07:53:05 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64 >>> Kernel build for GENERIC64 started on Wed Feb 22 07:53:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_timeout.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -m
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > On Tue, 21 Feb 2012, Steve Kargl wrote: > >> 3) Add a new option to ldconfig to prepend new libraries to >> the hints files and fix the ports to use this option instead >> of -m. > > You don't want system binaries that want /lib/libgcc_s.so.1 > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't > your option 3 do that? Why not? Would it cause problems? Is libgcc from GCC 4.6 incompatible with /lib/libgcc? If I understand correctly, the libgcc in base is pretty stripped down compared to "regular" libgcc, because most of that stuff is in our libc instead. So if there were compatibility problems, I'd expect those to show up when GCC 4.6 linked programs against /usr/local/.../libgcc and /lib/libc. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012, Steve Kargl wrote:
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
On 2012-02-21 20:42, Steve Kargl wrote:
...
Yes, /lib comes before /usr/local/lib/gcc46. I suppose
that this is a heads up for gerald@. lang/gcc is used by
the ports collections to build a large number of other
ports, so others are likely to hit this issue.
Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 => /lib/libgcc_s.so.1
723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
I think there is perhaps a little more to this issue of multiple
(incompatible) copies of a library with the same name being installed,
e.g. libcom_err in /usr/lib/libcom_err.so and
/usr/local/lib/libcom_err.so. An application using the library must
#include to get the library prototypes, but the preprocessor
puts the standard include search path /usr/include at the end of the
search list, even if it is specified explicitly on the command line,
unless -nostdinc is passed. So this will prefer the header from ports in
the absence of evil trickery.
I was pounding my head against this a couple years ago, so my memory is
not quite fresh, but I think that I could convince the compile-time link
step to use either version of the library with the appropriate ordering of
-L arguments (but I am in trouble if I want libkrb5.so from ports and
libcom_err.so from base!).
In any case, the dynamic linker will search the default search path
*first*, preferring the copy of the library from the base system. After
pounding my head against the issue for a while I concluded that I had no
option other than to use -rpath (but alas I ran out of time for that
particular project and never finished).
It is definitely an ugly situation and I have no good answers. It would
be nice to not have to specify every detail of what should be happening,
though.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
4) Suggestions from people that are brighter than I.
How would things break if we made everything in the base system specify
-rpath of /lib and /usr/lib as appropriate, and then put the ports
versions first in the default search path?
-Ben Kaduk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: Effect of Processor and Memory on KDE4 execution speed
On Tue, Feb 21, 2012 at 6:07 PM, Devin Teske wrote:
> On Tue, 2012-02-21 at 14:42 -0800, Robison, Dave wrote:
> >
> >
> > Original Message
> > Subject:
> > Effect of Processor and Memory on
> > KDE4 execution speed
> > Date:
> > Tue, 14 Feb 2012 09:39:36 -0500
> > From:
> > Mehmet Erol Sanliturk
> >
> >To:
> > FreeBSD Current
> >
> >
> >
> > Dear All ,
> >
> > Today I have encountered a case which I think informing you about it may
> be
> > useful .
> >
> > In my previous messages , I have mentioned very slowness of KDE4 .
> >
> >
> > Onto another computer I have installed DruidBSD 9.0 b56 amd64 , and KDE4
> .
> > In that installation KDE4 worked surprisingly fast .
> >
>
> Great! Glad to hear it's fast!
>
> Though, a couple corrections about the statement above.
>
> First correction:
>
> You meand "FreeBSD Druid", not "DruidBSD".
>
> The "FreeBSD Druid" is a FreeBSD installer.
> The "DruidBSD" is a micro distribution that can't/doesn't install
> anything.
>
> Second correction:
>
> The "FreeBSD Druid" installs a vanilla, completely unmodified
> RELENG_9_0_RELEASE copy of FreeBSD (albeit using sysinstall(8) instead
> of bsdinstall(8)).
>
>
> > To understand whether difference is among FreeBSD or DruidBSD , I have
> > installed
> > FreeBSD 9.0 Release amd64 and KDE4 on the same computer instead of
> DruidBSD
> > .
> >
> > The KDE4 has worked flawlesly i.e. , means very fast .
> >
>
> Cool. Glad to hear it's fast there too (makes sense; see below)
>
> With respect to the binaries that are being laid-down by the FreeBSD
> Druid, there is no difference in comparison to the official installer.
>
> However, the FreeBSD Druid does do some post-install configuration of
> the system that the official installer does not (though none of these
> customizations should have any effect on KDE in any way shape-or-form):
>
> 1. It enables sshd root login in /etc/ssh/sshd_config
> 2. It enables netwait in /etc/rc.conf (by adding netwait_enable="YES")
> 3. It installs perl-5.14 (as a package so if you don't want it, you can
> pkg_delete it to get rid of it)
> 4. It sets the root password
> 5. It installs /usr/local/sbin/host-setup
> 6. It configures root login-shell to be /usr/local/sbin/host-setup for
> easy setup on first-login (once exited, must be run manually henceforth)
> 7. It installs rsync (as a package, so if you don't want it you can
> pkg_delete it)
> 8. It installs bonnie (as a package; don't want -- pkg_delete)
> 9. Enables SU+J on /tmp /var and /usr
>
> None of these customizations should have any effect on system
> performance whatsoever.
>
> So I recommend not treating this as a "FreeBSD Druid" versus "FreeBSD"
> problem.
>
> NOTE: and again, "DruidBSD" is not an installable OS, only a micro Live
> Distribution used for doing rescues or simply booting into a mfs
> environment.
>
>
>
> > To make equivalent the installations on both computers , I have installed
> > FreeBSD 9.0 Release amd64 and KDE4 on the slow computer exactly as in
> fast
> > computer .
> >
>
> I'm confused.
>
> In the immediately-above paragraph you mention a fast computer and a
> slow computer. But in the paragraphs that proceeded it, I only see
> mention of fast-running KDE4.
>
> If you read the previous paragraphs carefully, you're stating that both
> installers ("FreeBSD Druid" and the official, both) produced fast-
> running installations of KDE4.
>
> Which is it?
>
>
>
"Fast computer" means "FreeBSD executed KDE4 fast" ( having Intel
processor E2220 ) ,
"Slow computers" means "FreeBSD executed KDE4 slow" ( having Intel
processor Q6600 ) ,
The problem is not generated by disk layouts , because sysinstall and
bsdinstall
are NOT factors on the problem : Only physical placement of memory chips in
the slots :
Rearranging memory chips in the slots or using a different chip set with
the same ( brand , model , speed ) is causing the problem or it is curing
the problem .
> >
> > Starting times after first boot ( to eliminate initialization effects )
> are
> > the following
> > ( All timings are from "root" ) :
> >
>
> Is this on the box that was installed with FreeBSD Druid or box
> installed with official 9.0-RELEASE media?
>
>
> > >From "startx" ( which contains "exec ... kde4 ..." )
> > to appearance of KDE menu symbol at the bottom left corner :
> >
> >
> > Fast computer : 8 GB : 0+ ( < 1 ) minute ( 4 x 2 GB )
> > Slow computer : 4 GB : 2+ ( < 3 ) minutes ( 2 x 2 GB ) ( 2 x ! GB chips
> > removed ) ,
> > 6 GB : 8+ ( < 9 ) minutes ( 2 x ( 2 , 1 ) GB ) .
> > ( Memory chip installation conforms to main board manual
> . )
> > ( The clock does not have second counter . )
> >
> > Fast Computer
> > CPU : Intel Pentium Dual CPU E2220 @ 2.40 GHz ( 2397.65-MHz K-8class
> CPU )
> > ACPI APIC Table : < INTEL DG965WH >
> >
> > Slow Computer
> > CPU : Int
Re: NICs not in GENERIC
On Tue, Feb 21, 2012 at 05:44:01PM -0700, Scott Long wrote: > > On Feb 21, 2012, at 10:51 AM, Navdeep Parhar wrote: > > > On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote: > >> Hi, > >> > >> is there a specific reason that the following NICs are not (or shall > >> not be) in GENERIC (at least on i386)? > > > > No specific reason for these two: > > > >> - if_cxgb > >> - if_cxgbe > > > > But I do prefer to load them as modules (and as late as possible -- > > after sysctl.conf has been processed and any nmbclusters, nmbjumboXX > > settings have taken affect). > > > > Other than root over NFS, is there any reason to have NIC drivers in > > GENERIC? > > > > GENERIC is the kernel profile that's used during installation, and the > installer (at one point in time) supported installing over NFS and FTP. If the installer itself can come up without the NIC driver it should be able to load any NIC driver KLD it wants and then reach the "install media" (NFS, FTP, etc.) over the network. Or is it that the installer's root fs didn't have any KLDs back then? Navdeep > GENERIC was also a good smoke test to see if FreeBSD would run on a newly > purchased machine, since it included most drivers. > > Scott > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl wrote:
> On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
> > On Tue, 21 Feb 2012, Steve Kargl wrote:
> >
> > >On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> > >>On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> > >>>On 2012-02-21 20:42, Steve Kargl wrote:
> > >>>...
> > Yes, /lib comes before /usr/local/lib/gcc46. I suppose
> > that this is a heads up for gerald@. lang/gcc is used by
> > the ports collections to build a large number of other
> > ports, so others are likely to hit this issue.
> > >>
> > >>Does -rpath not help ?
> > >
> > >I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
> > >to my various projects. I can also build with -static to avoid
> > >rtld. One can also use LD_LIBRARY_PATH.
> > >
> > >The issue seems to be that lang/gcc will be installed after
> > >system start, and 'ldconfig -m' appends new shared libraries
> > >to the hints file. This means that libraries with the same
> > >name but different locations will be found via the order of the
> > >search path in the hints file, and one gets the wrong library.
> > >That is, with the following
> > >
> > >troutmask:root[256] ldconfig -r | grep libgcc_s
> > > 29:-lgcc_s.1 => /lib/libgcc_s.so.1
> > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
> > >
> > >29 will be found before 723. While I can work around the
> > >issue, lang/gcc is used by a rather large boatload of ports
> > >during the building process and I suspect that a large
> > >number of FreeBSD users use lang/gcc for their everyday
> > >compiler. The question is how do we, the FreeBSD project,
> > >deal with this issue, so that the general user base does not
> > >get hit with it.
> > >
> > >There are a few solutions:
> > >1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
> > > be scanned before /lib and /usr/lib.
> > >2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
> > > for /lib and /usr/lib.
> >
> > s/for/before/ ??
>
> yes. sorry about the typo.
>
> >
> > >3) Add a new option to ldconfig to prepend new libraries to
> > > the hints files and fix the ports to use this option instead
> > > of -m.
> >
> > You don't want system binaries that want /lib/libgcc_s.so.1
> > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
> > your option 3 do that?
>
> Well, yes, I suppose that could be a problem. :)
>
> > >4) Suggestions from people that are brighter than I.
> >
Well, newer libgcc_s.so.1 should be backward compatible with older
ones, so that should not be the problem and if there are any, we need
to find and fix them.
> > [Not brighter than you, but]
> >
> > o For our system libgcc, use libcc_s.so.1 (or some other
> > name) instead of libgcc_s.so.1?
>
> Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
> and binaries installed by lang/gcc updated to use this library.
>
'shared' portion of libgcc was meant to _be_ shared specifically and in
general having two copies of unwind code and two copied of unwind
frames handling logic is probably not what GCC is expecting.
> > o Change affected ports to use -rpath when building?
>
> I started to look into this option, but it quickly becomes
> apparent that some (evil) configure hackery may be needed.
>
It can be done in GCC specs for all the programs that use CC driver to
to the linking. Of course, all direct LD invocations will need to be
found and fixed as well, but those were always fragile anyway.
> --
> Steve
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: NICs not in GENERIC
On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote: > Hi, > > is there a specific reason that the following NICs are not (or shall > not be) in GENERIC (at least on i386)? > - if_cas: is compiled as a module, Sun hardware, non-x86 only? > - if_cxgb > - if_cxgbe Last time I tried cas(4) on i386, it worked without problems and I think all Sun add-on cards would work. However as Scott said, it would be rare to see these Sun controllers on x86 world. > - if_gem: is compiled as a module, Apple/Sun, non-x86 only? > - if_hme: is compiled as a module, Sun hardware, non-x86 only? > - if_ic: no man-page > - if_ipheth: no man-page > - if_mos: USB NIC > - if_mxge > - if_my > - if_nxge > - if_vtnet: virtual NIC for hypervisors > > Bye, > Alexander. > > -- > Progress might have been all right once, but it's gone on too long. > -- Ogden Nash > > http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 11:42:59 -0800 Steve Kargl wrote: > On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > > > > > troutmask:kargl[210] halfspace > > > /lib/libgcc_s.so.1: version GCC_4.6.0 required > > > by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] > > > > > > (Note, the annoying absense of a newline character after the error > > > message, which is a completely different issue.) > > > > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > > > > > troutmask:kargl[212] ldd ~/bin/halfspace > > > /home/kargl/bin/halfspace: > > > liblapack.so.4 => /usr/local/lib/liblapack.so.4 > > > (0x2008c3000) libblas.so.2 => /usr/local/lib/libblas.so.2 > > > (0x201463000) libgfortran.so.3 > > > => /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 > > > => /lib/libm.so.5 (0x201a7) libgcc_s.so.1 > > > => /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 > > > => /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 > > > => /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r > > > | grep libgcc_s 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > > > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > > > the lang/gcc port is no longer providing sufficient information > > > for rtld to choose the correct library. > > > > > > I have reverted revisions 230784, 299768, and 229508 (and > > > various combinitions of these revisions) from rtld-elf. The > > > result does not change the above error. > > > > > > I can work around the problem by specifying -static during > > > the building of my programs. Or, I can work around the > > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > > command line, which I have never had to do. > > > > > I highly suspect that you just happen to not need a symbol from the > > newest namespace before. > > > > The thing to look first is the library search path in the ld.so > > hints, which is output at the second line of ldconfig -r. I think > > that you have /lib before /usr/local/lib/gcc46 in your setup. This > > guess is confirmed by the numeration of the two instances of gcc_s > > above. Either change the config, or use -rpath. AFAIR, ldconfig -m > > adds the directory at the end of the search list. > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > that this is a heads up for gerald@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. > > I tried reading rtld.c to see where the issue lies. One > possibility seems to be a change in rtld.c (lines 4012-13) > to remember the version mismatch, then continuing the search > to see if another library with the same name but different > location matches. After exhausting the list of directories > in the search path, either an error is reported or a match > has been found. Note, I'm still trying to parse and understand > the rtld.c code, so may be what I'm suggesting is not > feasible. > This was suggested before in a slightly different context and at the time I was not big fan of the idea. With more ports starting to use out of tree GCC, maybe we need to revisit the idea. There are corner cases that I do not know how to handle in this approach: what happens if we have mapped system libgcc_s.so.1 already which did satisfy all the requirements and later a new library gets mapped in dynamically and requires symbol versions from newer GCC? Going with this suggestion will likely involve substantial changes into rtld dependency walking code - we'll need to make a graph traversal and collect all the version information from all the libraries that might satisfy the search before doing the final pass of loading the winning candidates, which implies at least two dependency tree passes. And, given the above, it won't even give us what we want anyway as long as there's dlopen in the picture, so I'd say it is not worth the trouble. Just changing the compiler to supply rpath on binaries it builds might be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware, etc) are doing this for ages and mostly manage to pull things off. Third option is of course purging _all_ toolchain components out of the tree, which is such a fine bikeshed material that I am a bit scared to bring that up. -- Alexander Kabaev signature.asc Description: PGP signature
Re: NICs not in GENERIC
On Feb 21, 2012, at 10:51 AM, Navdeep Parhar wrote: > On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote: >> Hi, >> >> is there a specific reason that the following NICs are not (or shall >> not be) in GENERIC (at least on i386)? > > No specific reason for these two: > >> - if_cxgb >> - if_cxgbe > > But I do prefer to load them as modules (and as late as possible -- > after sysctl.conf has been processed and any nmbclusters, nmbjumboXX > settings have taken affect). > > Other than root over NFS, is there any reason to have NIC drivers in > GENERIC? > GENERIC is the kernel profile that's used during installation, and the installer (at one point in time) supported installing over NFS and FTP. GENERIC was also a good smoke test to see if FreeBSD would run on a newly purchased machine, since it included most drivers. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NICs not in GENERIC
On Feb 21, 2012, at 7:56 AM, Alexander Leidinger wrote: > Hi, > > is there a specific reason that the following NICs are not (or shall not be) > in GENERIC (at least on i386)? > - if_cas: is compiled as a module, Sun hardware, non-x86 only? > - if_gem: is compiled as a module, Apple/Sun, non-x86 only? > - if_hme: is compiled as a module, Sun hardware, non-x86 only? If these aren't for i386 hardware, then why would they need to be in the i386 GENERIC profile? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012, Steve Kargl wrote:
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
On 2012-02-21 20:42, Steve Kargl wrote:
...
Yes, /lib comes before /usr/local/lib/gcc46. I suppose
that this is a heads up for gerald@. lang/gcc is used by
the ports collections to build a large number of other
ports, so others are likely to hit this issue.
Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 => /lib/libgcc_s.so.1
723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
s/for/before/ ??
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
You don't want system binaries that want /lib/libgcc_s.so.1
to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
your option 3 do that?
4) Suggestions from people that are brighter than I.
[Not brighter than you, but]
o For our system libgcc, use libcc_s.so.1 (or some other
name) instead of libgcc_s.so.1?
o Change affected ports to use -rpath when building?
--
DE
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
> On Tue, 21 Feb 2012, Steve Kargl wrote:
>
> >On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> >>On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> >>>On 2012-02-21 20:42, Steve Kargl wrote:
> >>>...
> Yes, /lib comes before /usr/local/lib/gcc46. I suppose
> that this is a heads up for gerald@. lang/gcc is used by
> the ports collections to build a large number of other
> ports, so others are likely to hit this issue.
> >>
> >>Does -rpath not help ?
> >
> >I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
> >to my various projects. I can also build with -static to avoid
> >rtld. One can also use LD_LIBRARY_PATH.
> >
> >The issue seems to be that lang/gcc will be installed after
> >system start, and 'ldconfig -m' appends new shared libraries
> >to the hints file. This means that libraries with the same
> >name but different locations will be found via the order of the
> >search path in the hints file, and one gets the wrong library.
> >That is, with the following
> >
> >troutmask:root[256] ldconfig -r | grep libgcc_s
> > 29:-lgcc_s.1 => /lib/libgcc_s.so.1
> > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
> >
> >29 will be found before 723. While I can work around the
> >issue, lang/gcc is used by a rather large boatload of ports
> >during the building process and I suspect that a large
> >number of FreeBSD users use lang/gcc for their everyday
> >compiler. The question is how do we, the FreeBSD project,
> >deal with this issue, so that the general user base does not
> >get hit with it.
> >
> >There are a few solutions:
> >1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
> > be scanned before /lib and /usr/lib.
> >2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
> > for /lib and /usr/lib.
>
> s/for/before/ ??
yes. sorry about the typo.
>
> >3) Add a new option to ldconfig to prepend new libraries to
> > the hints files and fix the ports to use this option instead
> > of -m.
>
> You don't want system binaries that want /lib/libgcc_s.so.1
> to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
> your option 3 do that?
Well, yes, I suppose that could be a problem. :)
> >4) Suggestions from people that are brighter than I.
>
> [Not brighter than you, but]
>
> o For our system libgcc, use libcc_s.so.1 (or some other
> name) instead of libgcc_s.so.1?
Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
and binaries installed by lang/gcc updated to use this library.
> o Change affected ports to use -rpath when building?
I started to look into this option, but it quickly becomes
apparent that some (evil) configure hackery may be needed.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On 2/21/2012 23:32, Steve Kargl wrote: > On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote: >> On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: >>> On 2012-02-21 20:42, Steve Kargl wrote: >>> ... Yes, /lib comes before /usr/local/lib/gcc46. I suppose that this is a heads up for gerald@. lang/gcc is used by the ports collections to build a large number of other ports, so others are likely to hit this issue. >> >> Does -rpath not help ? > > I already mentioned that I can add '-rpath /usr/local/lib/gcc46' > to my various projects. I can also build with -static to avoid > rtld. One can also use LD_LIBRARY_PATH. Make sure it's your binary pulling in libgcc_s. I just went through a few iterations of recompiling mplayer with different *FLAGS and each time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and saw libschroedinger was the one actually pulling it in. Recompiled libschroedinger with gcc46 by putting USE_GCC=46 in the Makefile and sure enough: % ldd `which mplayer`|grep gcc libgcc_s.so.1 => /usr/local/lib/gcc46/libgcc_s.so.1 (0x29625000) In short, bsd.gcc.mk is doing the right thing, but dependencies may screw things up. -- Mel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Wed, Feb 22, 2012 at 12:22:50AM +0100, Mel Flynn wrote: > On 2/21/2012 23:32, Steve Kargl wrote: > > On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote: > >> On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: > >>> On 2012-02-21 20:42, Steve Kargl wrote: > >>> ... > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > that this is a heads up for gerald@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. > >> > >> Does -rpath not help ? > > > > I already mentioned that I can add '-rpath /usr/local/lib/gcc46' > > to my various projects. I can also build with -static to avoid > > rtld. One can also use LD_LIBRARY_PATH. > > Make sure it's your binary pulling in libgcc_s. I just went through a > few iterations of recompiling mplayer with different *FLAGS and each > time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and > saw libschroedinger was the one actually pulling it in. > I already did the ldd song and dance. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fwd: Effect of Processor and Memory on KDE4 execution speed
On Tue, 2012-02-21 at 14:42 -0800, Robison, Dave wrote:
>
>
> Original Message
> Subject:
> Effect of Processor and Memory on
> KDE4 execution speed
> Date:
> Tue, 14 Feb 2012 09:39:36 -0500
> From:
> Mehmet Erol Sanliturk
>
>To:
> FreeBSD Current
>
>
>
> Dear All ,
>
> Today I have encountered a case which I think informing you about it may be
> useful .
>
> In my previous messages , I have mentioned very slowness of KDE4 .
>
>
> Onto another computer I have installed DruidBSD 9.0 b56 amd64 , and KDE4 .
> In that installation KDE4 worked surprisingly fast .
>
Great! Glad to hear it's fast!
Though, a couple corrections about the statement above.
First correction:
You meand "FreeBSD Druid", not "DruidBSD".
The "FreeBSD Druid" is a FreeBSD installer.
The "DruidBSD" is a micro distribution that can't/doesn't install
anything.
Second correction:
The "FreeBSD Druid" installs a vanilla, completely unmodified
RELENG_9_0_RELEASE copy of FreeBSD (albeit using sysinstall(8) instead
of bsdinstall(8)).
> To understand whether difference is among FreeBSD or DruidBSD , I have
> installed
> FreeBSD 9.0 Release amd64 and KDE4 on the same computer instead of DruidBSD
> .
>
> The KDE4 has worked flawlesly i.e. , means very fast .
>
Cool. Glad to hear it's fast there too (makes sense; see below)
With respect to the binaries that are being laid-down by the FreeBSD
Druid, there is no difference in comparison to the official installer.
However, the FreeBSD Druid does do some post-install configuration of
the system that the official installer does not (though none of these
customizations should have any effect on KDE in any way shape-or-form):
1. It enables sshd root login in /etc/ssh/sshd_config
2. It enables netwait in /etc/rc.conf (by adding netwait_enable="YES")
3. It installs perl-5.14 (as a package so if you don't want it, you can
pkg_delete it to get rid of it)
4. It sets the root password
5. It installs /usr/local/sbin/host-setup
6. It configures root login-shell to be /usr/local/sbin/host-setup for
easy setup on first-login (once exited, must be run manually henceforth)
7. It installs rsync (as a package, so if you don't want it you can
pkg_delete it)
8. It installs bonnie (as a package; don't want -- pkg_delete)
9. Enables SU+J on /tmp /var and /usr
None of these customizations should have any effect on system
performance whatsoever.
So I recommend not treating this as a "FreeBSD Druid" versus "FreeBSD"
problem.
NOTE: and again, "DruidBSD" is not an installable OS, only a micro Live
Distribution used for doing rescues or simply booting into a mfs
environment.
> To make equivalent the installations on both computers , I have installed
> FreeBSD 9.0 Release amd64 and KDE4 on the slow computer exactly as in fast
> computer .
>
I'm confused.
In the immediately-above paragraph you mention a fast computer and a
slow computer. But in the paragraphs that proceeded it, I only see
mention of fast-running KDE4.
If you read the previous paragraphs carefully, you're stating that both
installers ("FreeBSD Druid" and the official, both) produced fast-
running installations of KDE4.
Which is it?
>
> Starting times after first boot ( to eliminate initialization effects ) are
> the following
> ( All timings are from "root" ) :
>
Is this on the box that was installed with FreeBSD Druid or box
installed with official 9.0-RELEASE media?
> >From "startx" ( which contains "exec ... kde4 ..." )
> to appearance of KDE menu symbol at the bottom left corner :
>
>
> Fast computer : 8 GB : 0+ ( < 1 ) minute ( 4 x 2 GB )
> Slow computer : 4 GB : 2+ ( < 3 ) minutes ( 2 x 2 GB ) ( 2 x ! GB chips
> removed ) ,
> 6 GB : 8+ ( < 9 ) minutes ( 2 x ( 2 , 1 ) GB ) .
> ( Memory chip installation conforms to main board manual . )
> ( The clock does not have second counter . )
>
> Fast Computer
> CPU : Intel Pentium Dual CPU E2220 @ 2.40 GHz ( 2397.65-MHz K-8class CPU )
> ACPI APIC Table : < INTEL DG965WH >
>
> Slow Computer
> CPU : Intel Core 2 QUAD CPU Q6600 @ 2.40 GHz ( 2397.65-MHz K-8class CPU )
> ACPI APIC Table : < INTEL DG965WH >
>
> ( The main boards are the same ) .
> ( All of the memory chips are the same : Kingston HyperX 800 MHz )
>
In your metrics above, which machine (fast vs slow) was installed with
which installer?
> I could not understand the reason(s) of the differences .
>
Disk partitions? (I'm guessing).
There's really no difference between what the official 9.0-RELEASE
installer installs and what the FreeBSD Druid installs. They were both
compiled from RELENG_9_0_RELEASE within a day from each other. The
likelihood that the binaries would differ with respect to code they were
compiled from is highly unlikely.
NOTE: The installed kernel should even have the same MD5 (can't say the
same fo
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> > On 2012-02-21 20:42, Steve Kargl wrote:
> > ...
> > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose
> > > that this is a heads up for gerald@. lang/gcc is used by
> > > the ports collections to build a large number of other
> > > ports, so others are likely to hit this issue.
>
> Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 => /lib/libgcc_s.so.1
723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
4) Suggestions from people that are brighter than I.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: > On 2012-02-21 20:42, Steve Kargl wrote: > ... > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > > that this is a heads up for gerald@. lang/gcc is used by > > the ports collections to build a large number of other > > ports, so others are likely to hit this issue. Does -rpath not help ? man ld -rpath dir Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option. If -rpath is not used when linking an ELF executable, the contents of the environment variable "LD_RUN_PATH" will be used if it is defined. Or is this another problem? -rpath is added in /usr/ports/Mk > However, at runtime, it links against the system libstdc++: I ran into this with two of my own ports. -rpath needed to be passed to ld. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On 2012-02-21 20:42, Steve Kargl wrote: ... > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > that this is a heads up for gerald@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. The same applies to libstdc++.so.6, if you compile any C++ program with e.g. g++46. During the link stage, g++ sets the library path so that /usr/local/lib/gcc46/libstdc++.so is linked against the program: ... COMPILER_PATH=/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/bin/ LIBRARY_PATH=/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib/:/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-o' 'cpptest' '-v' '-shared-libgcc' '-mtune=generic' '-march=i486' /usr/local/libexec/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/collect2 --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o cpptest /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtbegin.o -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3 -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../../../../i386-portbld-freebsd10.0/lib -L/usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/../../.. cpptest.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc46/gcc/i386-portbld-freebsd10.0/4.6.3/crtend.o /usr/lib/crtn.o However, at runtime, it links against the system libstdc++: $ ldd ./cpptest ./cpptest: libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28098000) libm.so.5 => /lib/libm.so.5 (0x28171000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2818d000) libc.so.7 => /lib/libc.so.7 (0x28198000) Some (simple) C++ programs handle this just fine, others die horribly... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 11:42:59AM -0800, Steve Kargl wrote: > On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > > > > > troutmask:kargl[210] halfspace > > > /lib/libgcc_s.so.1: version GCC_4.6.0 required by > > > /home/kargl/bin/halfspace > > > not foundtroutmask:kargl[211] > > > > > > (Note, the annoying absense of a newline character after the error > > > message, which is a completely different issue.) > > > > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > > > > > troutmask:kargl[212] ldd ~/bin/halfspace > > > /home/kargl/bin/halfspace: > > > liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) > > > libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) > > > libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 > > > (0x20175d000) > > > libm.so.5 => /lib/libm.so.5 (0x201a7) > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) > > > libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 > > > (0x201ea2000) > > > libc.so.7 => /lib/libc.so.7 (0x2020d6000) > > > troutmask:kargl[212] ldconfig -r | grep libgcc_s > > > 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > > > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > > > the lang/gcc port is no longer providing sufficient information > > > for rtld to choose the correct library. > > > > > > I have reverted revisions 230784, 299768, and 229508 (and > > > various combinitions of these revisions) from rtld-elf. The > > > result does not change the above error. > > > > > > I can work around the problem by specifying -static during > > > the building of my programs. Or, I can work around the > > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > > command line, which I have never had to do. > > > > > I highly suspect that you just happen to not need a symbol from the > > newest namespace before. > > > > The thing to look first is the library search path in the ld.so hints, > > which is output at the second line of ldconfig -r. I think that you have > > /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed > > by the numeration of the two instances of gcc_s above. Either change > > the config, or use -rpath. AFAIR, ldconfig -m adds the directory > > at the end of the search list. > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > that this is a heads up for gerald@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. > > I tried reading rtld.c to see where the issue lies. One > possibility seems to be a change in rtld.c (lines 4012-13) > to remember the version mismatch, then continuing the search > to see if another library with the same name but different > location matches. After exhausting the list of directories > in the search path, either an error is reported or a match > has been found. Note, I'm still trying to parse and understand > the rtld.c code, so may be what I'm suggesting is not > feasible. No, it is not feasible. The version check that tripped is there to check consistency, and not to start loading. In fact, it is too late to load other library (with the same name). The configuration needs to be fixed, and not the rtld. pgpxjeQZdJNRo.pgp Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > > > troutmask:kargl[210] halfspace > > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace > > not foundtroutmask:kargl[211] > > > > (Note, the annoying absense of a newline character after the error > > message, which is a completely different issue.) > > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > > > troutmask:kargl[212] ldd ~/bin/halfspace > > /home/kargl/bin/halfspace: > > liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) > > libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) > > libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 > > (0x20175d000) > > libm.so.5 => /lib/libm.so.5 (0x201a7) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) > > libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 > > (0x201ea2000) > > libc.so.7 => /lib/libc.so.7 (0x2020d6000) > > troutmask:kargl[212] ldconfig -r | grep libgcc_s > > 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > > the lang/gcc port is no longer providing sufficient information > > for rtld to choose the correct library. > > > > I have reverted revisions 230784, 299768, and 229508 (and > > various combinitions of these revisions) from rtld-elf. The > > result does not change the above error. > > > > I can work around the problem by specifying -static during > > the building of my programs. Or, I can work around the > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > command line, which I have never had to do. > > > I highly suspect that you just happen to not need a symbol from the > newest namespace before. > > The thing to look first is the library search path in the ld.so hints, > which is output at the second line of ldconfig -r. I think that you have > /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed > by the numeration of the two instances of gcc_s above. Either change > the config, or use -rpath. AFAIR, ldconfig -m adds the directory > at the end of the search list. Yes, /lib comes before /usr/local/lib/gcc46. I suppose that this is a heads up for gerald@. lang/gcc is used by the ports collections to build a large number of other ports, so others are likely to hit this issue. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > Sorry about the cross post, but I can't tell if this > a -current issue of a -ports issue. Unfortunately, > I updated my freebsd 10.0 systems and the lang/gcc > port during the same timeframe. > > I have compiled my math library and several programs > with gfortran, which is installed by lang/gcc (pkg_info > shows gcc-4.6.2_1). When I try running the program > I get > > troutmask:kargl[210] halfspace > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace > not foundtroutmask:kargl[211] > > (Note, the annoying absense of a newline character after the error > message, which is a completely different issue.) > > I see this problem on both freebsd-i386 and freebsd-amd64. > > troutmask:kargl[212] ldd ~/bin/halfspace > /home/kargl/bin/halfspace: > liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) > libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) > libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 > (0x20175d000) > libm.so.5 => /lib/libm.so.5 (0x201a7) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) > libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 > (0x201ea2000) > libc.so.7 => /lib/libc.so.7 (0x2020d6000) > troutmask:kargl[212] ldconfig -r | grep libgcc_s > 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > the lang/gcc port is no longer providing sufficient information > for rtld to choose the correct library. > > I have reverted revisions 230784, 299768, and 229508 (and > various combinitions of these revisions) from rtld-elf. The > result does not change the above error. > > I can work around the problem by specifying -static during > the building of my programs. Or, I can work around the > problem by *explicitly* adding '-rpath /usr/local/lib' to the > command line, which I have never had to do. > I highly suspect that you just happen to not need a symbol from the newest namespace before. The thing to look first is the library search path in the ld.so hints, which is output at the second line of ldconfig -r. I think that you have /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed by the numeration of the two instances of gcc_s above. Either change the config, or use -rpath. AFAIR, ldconfig -m adds the directory at the end of the search list. pgpXcBSnHGVyN.pgp Description: PGP signature
rtld or lang/gcc cannot find libgcc_s.so.1
Sorry about the cross post, but I can't tell if this a -current issue of a -ports issue. Unfortunately, I updated my freebsd 10.0 systems and the lang/gcc port during the same timeframe. I have compiled my math library and several programs with gfortran, which is installed by lang/gcc (pkg_info shows gcc-4.6.2_1). When I try running the program I get troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 => /lib/libm.so.5 (0x201a7) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 => /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r | grep libgcc_s 29:-lgcc_s.1 => /lib/libgcc_s.so.1 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NICs not in GENERIC
On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote: > Hi, > > is there a specific reason that the following NICs are not (or shall > not be) in GENERIC (at least on i386)? No specific reason for these two: > - if_cxgb > - if_cxgbe But I do prefer to load them as modules (and as late as possible -- after sysctl.conf has been processed and any nmbclusters, nmbjumboXX settings have taken affect). Other than root over NFS, is there any reason to have NIC drivers in GENERIC? Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NICs not in GENERIC
On 02/21/12 09:56, Alexander Leidinger wrote: Hi, is there a specific reason that the following NICs are not (or shall not be) in GENERIC (at least on i386)? <> - if_mxge <> Speaking for mxge, it requires the better part of 1MB worth of firmware files, and it is a rather uncommon device. I never added it to GENERIC because I was trying to avoid bloating the kernel. It works just fine as a module. Drew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
AMD K15 sensor support
I was wondering if anyone is aware of any ongoing effort to support the on CPU temp sensors on the AMD K15 CPU's amdtemp only supports up to K11 so far as I can tell Sam Fourman Jr. Titan# dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r231712: Tue Feb 14 15:46:59 CST 2012 root@Titan:/usr/obj/usr/src/sys/TITAN amd64 WARNING: WITNESS option enabled, expect reduced performance. link_elf_obj: symbol PHYS_TO_VM_PAGE undefined KLD file vboxdrv.ko - could not finalize loading module_register: module pci/sdhci already exists! Module pci/sdhci failed to register: 17 CPU: AMD FX(tm)-6100 Six-Core Processor (3624.21-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x600f12 Family = 15 Model = 1 Stepping = 2 Features=0x178bfbff Features2=0x1e98220b AMD Features=0x2e500800 AMD Features2=0x1c9bfff,> TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16497942528 (15733 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ctl: CAM Target Layer loaded cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cfca (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 atrtc0: port 0x70-0x73 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 18 at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xf800-0xf9ff,0xd000-0xd7ff,0xdc00-0xdfff irq 18 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xfbffc000-0xfbff irq 19 at device 0.1 on pci1 pcib2: irq 17 at device 9.0 on pci0 pci2: on pcib2 xhci0: mem 0xfd1f8000-0xfd1f irq 17 at device 0.0 on pci2 xhci0: 64 byte context size. usbus0 on xhci0 pcib3: irq 18 at device 10.0 on pci0 pci3: on pcib3 ahci0: port 0xef00-0xef07,0xee00-0xee03,0xed00-0xed07,0xec00-0xec03,0xeb00-0xeb0f mem 0xfdbff000-0xfdbff1ff irq 18 at device 0.0 on pci3 ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahci1: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfdfff000-0xfdfff3ff irq 19 at device 17.0 on pci0 ahci1: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ahcich2: at channel 0 on ahci1 ahcich3: at channel 1 on ahci1 ahcich4: at channel 2 on ahci1 ahcich5: at channel 3 on ahci1 ahcich6: at channel 4 on ahci1 ahcich7: at channel 5 on ahci1 ohci0: mem 0xfdffe000-0xfdffefff irq 18 at device 18.0 on pci0 usbus1: on ohci0 ehci0: mem 0xfdffd000-0xfdffd0ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 ohci1: mem 0xfdffc000-0xfdffcfff irq 18 at device 19.0 on pci0 usbus3: on ohci1 ehci1: mem 0xfdffb000-0xfdffb0ff irq 17 at device 19.2 on pci0 usbus4: EHCI version 1.0 usbus4: on ehci1 pci0: at device 20.0 (no driver attached) hdac1: mem 0xfdff4000-0xfdff7fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pci4: on pcib4 fwohci0: port 0xbf00-0xbf7f mem 0xfddff000-0xfddff7ff irq 22 at device 14.0 on pci4 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:49:e5:50:51:51:05:00 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xcfd84000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:49:e5:51:05:00 fwe0: Ethernet address: 02:49:e5:51:05:00 fwip0: on firewire0 fwip0: Firewire address: 00:49:e5:50:51:51:05:00 @ 0xfffe, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode ohci2: mem 0xfdffa000-0xfdffafff irq 18 at device 20.5 on pci0 usbus5:
NICs not in GENERIC
Hi, is there a specific reason that the following NICs are not (or shall not be) in GENERIC (at least on i386)? - if_cas: is compiled as a module, Sun hardware, non-x86 only? - if_cxgb - if_cxgbe - if_gem: is compiled as a module, Apple/Sun, non-x86 only? - if_hme: is compiled as a module, Sun hardware, non-x86 only? - if_ic: no man-page - if_ipheth: no man-page - if_mos: USB NIC - if_mxge - if_my - if_nxge - if_vtnet: virtual NIC for hypervisors Bye, Alexander. -- Progress might have been all right once, but it's gone on too long. -- Ogden Nash http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT] modular kernel config
Hi, I created a kernel config for i386/amd64 (should work on -current and 9.x) and a suitable loader.conf which: - tries to provide as much features as GENERIC (I lost one or two disk controllers, they are not available as a module... or I didn't find them) - incorporates some more features based upon a poll on stable@ (see below) - loads as much as possible as a module I've compile-tested them on i386 and amd64, but I didn't had time yet to give it a try on a spare machine. I may get some time next week to test (i386 only). It would be nice if someone could help testing: - compile the kernel - make _sure_ you have a way to recover the system in case the new kernel+loader.conf fails - verify that the example loader.conf contains all devices which are important for you - copy the example loader.conf to /boot/loader.conf - give it a try You can download from http://www.Leidinger.net/FreeBSD/current-patches/ The files are - i386_SMALL - i386_SMALL_loader.conf - amd64_SMALL - amd64_SMALL_loader.conf I didn't provide direct links for eqch one on purpose. If you do not know how to recover a system with an unsuitable loader.conf, don't give this a try (you could check a diff between GENERIC and SMALL, and make sure all removed devices which are imporant for you are in the loader.conf). They should work on -current and on 9.x, for 8.x I'm not sure if it woll work without removing some stuff (GENERIC on 8.x comes without some more debugging options, make sure you don't get surprised by them, but those may not be the only differences). I didn't use the name MODULAR on purpose, I've chosen a name where the first letter does not yet exist in the kernel config directory, to make tab-completion more easy. If you are not happy with the name, keep your opinion for yourself please, until after you tested this on a (maybe virtual) system. The loader.conf was generated with a script from a diff between GENERIC and SMALL, if there's a name mismatch between the config-name and the module-name, the script may have missed the module (I added some missing sound modules, but I may have overlooked something). You better double-check before giving it a try. The loader.conf is also supposed to disable some features (at the end of the file) which are new compared to what is in GENERIC, if the particular feature could cause a change in behavior. The new stuff in the kernel config compared to GENERIC is (in order of number of requests from users): - IPSEC (+ device enc + IPSEC_NAT_T) - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in loader.conf) - IPFIREWALL_FORWARD (touches every packet, power users which need a bigger PPS but not this feature can recompile the kernel, discussed with julian@) - FLOWTABLE (disabled in loader.conf) - BPF_JITTER In the poll there where some more options requested, but most of them can be handled via the loader or sysctl (e.g. the firewalls can be loaded as modules). For some of them I added some comments at the end of the SMALL config to make it more easy to find the correct way of configuring them. Doc-committers may want to have a look, maybe there's an opportunity to improve existing documentation. I'm interested in success reports, failure reports, and reports about missing stuff in loader.conf (mainly compared to the devices available in GENERIC, but missing stuff which could help getting a system installed and booted is welcome even if what you propose is not in GENERIC). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: devd based AUTOMOUNTER
Hi, I have created a PORT at last, its in the 'port' directory in the usual place: https://github.com/vermaden/automount/ Its my first PORT so feel free to bash me about my mistakes ;) After latest 'commits' I think that its ready for day-to-day use. To make 'full advantage' of *automount* install these ports: sysutils/ntfsprogs sysutils/fusefs-ntfs sysutils/fusefs-ext4fuse sysutils/fusefs-exfat I will try to add these ports as OPTIONS in the Makefile later. I will have to think about creating a man page through ... Feel free to submit Your propositions about next changes/development, because I think that I already created everything 'I' needed. Regards, vermaden --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/pc98
TB --- 2012-02-21 09:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-02-21 09:40:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2012-02-21 09:40:00 - cleaning the object tree TB --- 2012-02-21 09:40:00 - cvsupping the source tree TB --- 2012-02-21 09:40:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2012-02-21 09:40:55 - building world TB --- 2012-02-21 09:40:55 - CROSS_BUILD_TESTING=YES TB --- 2012-02-21 09:40:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-21 09:40:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-21 09:40:55 - SRCCONF=/dev/null TB --- 2012-02-21 09:40:55 - TARGET=pc98 TB --- 2012-02-21 09:40:55 - TARGET_ARCH=i386 TB --- 2012-02-21 09:40:55 - TZ=UTC TB --- 2012-02-21 09:40:55 - __MAKE_CONF=/dev/null TB --- 2012-02-21 09:40:55 - cd /src TB --- 2012-02-21 09:40:55 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 21 09:40:56 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] c++ -O2 -pipe -I/src/lib/clang/libclangdriver/../../../contrib/llvm/include -I/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver -I. -I/src/lib/clang/libclangdriver/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/Tool.cpp c++ -O2 -pipe -I/src/lib/clang/libclangdriver/../../../contrib/llvm/include -I/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver -I. -I/src/lib/clang/libclangdriver/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/ToolChain.cpp c++ -O2 -pipe -I/src/lib/clang/libclangdriver/../../../contrib/llvm/include -I/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver -I. -I/src/lib/clang/libclangdriver/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_HOSTTRIPLE=\"i386-unknown-freebsd10.0\" -fstack-protector -fno-exceptions -fno-rtti -c /src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp /src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp: In member function 'virtual clang::driver::DerivedArgList* clang::driver::toolchains::Darwin::TranslateArgs(const clang::driver::DerivedArgList&, const char*) const': /src/lib/clang/libclangdriver/../../../contrib/llvm/tools/clang/lib/Driver/ToolChains.cpp:753: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /src/lib/clang/libclangdriver. *** Error code 1 Stop in /src/lib/clang. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-21 10:27:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-21 10:27:58 - ERROR: failed to build world TB --- 2012-02-21 10:27:58 - 2277.55 user 391.45 system 2878.17 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
