10-CURRENT - LOR (lock order reversal)
Hi, these represent machine lockups, if not false positives. http://www.freebsd.org/cgi/query-pr.cgi?pr=182139cat= jb ___ 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: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote:
Hi Matthew,
2013/9/16 Matthew Fleming m...@freebsd.org:
Would it be possible to enable this only for devd, init, and clang binaries?
Or is it a matter of enabling it for library builds that are linked
statically with the mentioned binaries?
For it to have effect, it has to be enabled for both the libraries and
the binaries. The libraries need to be built with
-f{data,function}-sections. The binaries can also be built with those
flags, but it is actually more important to link with --gc-sections.
Could init/devd be made smaller by
finding out which functions they do/don't use and separating those into
separate .c files?
Also trying to answer Tim and Adrian's questions at the same time.
I've just taken a look at init and devd to see why the difference in
size is so big:
init seems to pull in the following things:
- Sun RPC,
- XDR,
- YP,
- res_*,
- All of the jemalloc profiling/stats code,
- Some widechar functions,
- malloc-related utility functions that are not used (posix_memalign,
aligned_alloc),
- Some stdio bloat,
- All sorts of termios tc* functions.
devd seems to pull in these:
- A very big pile of C++ symbols, as libc++ places many functions in a
single file.
- jemalloc profiling/stats again,
- A big pile of pthread,
- Maybe *_l() functions, which are of course rarely used.
Honestly, I think we can assume we'll never reach the point where all
the components listed above will properly have all functions
partitioned over separate compilation units.
I suspect that it would make a lot of sense to at least enable these
build flags for our core libraries (libc, libc++, libpthread,
libcompiler_rt, libcxxrt, etc). We could also enable it on
INTERNALLIBs (libraries that are not installed into /usr/lib), as for
these libraries, it would of course not come at any cost.
Would that sound okay?
I think this is a wrong direction. First, the split should be done at
the source level, as it was usually done forever. One of the offender
there was you, AFAIR.
Second, I would rather see init and devd, and in fact all other statically
linked binaries from our base system, to become dynamically linked. At
least I added a knob for building toolchain dynamic, but avoided the
fight of making this default.
pgpf4ASNxyWm0.pgp
Description: PGP signature
Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
On Sun, 15 Sep 2013 19:30:01 -0700 Tim Kientzle kient...@freebsd.org wrote: On Sep 15, 2013, at 2:24 PM, Ed Schouten e...@80386.nl wrote: GCC and Clang support the -ffunction-sections and -fdata-sections flags. Essentially, these flags force the compiler to put every function and variable in its own section. Though this will blow up the …. - devd suddenly becomes 500 KB in size, instead of a megabyte, - init's size drops from 900 KB to 600 KB, Can you figure out what functions are getting omitted when you make this change? You can add -Wl,--print-gc-sections to LDFLAGS to print which sections the linker is removing. Andrew ___ 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: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
(Copy for the list, wrong from address problem ...) On 18/09/2013, at 4:22 PM, Konstantin Belousov kostik...@gmail.com wrote: On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote: [...] Honestly, I think we can assume we'll never reach the point where all the components listed above will properly have all functions partitioned over separate compilation units. I suspect that it would make a lot of sense to at least enable these build flags for our core libraries (libc, libc++, libpthread, libcompiler_rt, libcxxrt, etc). We could also enable it on INTERNALLIBs (libraries that are not installed into /usr/lib), as for these libraries, it would of course not come at any cost. Would that sound okay? I think this is a wrong direction. First, the split should be done at the source level, as it was usually done forever. One of the offender there was you, AFAIR. Second, I would rather see init and devd, and in fact all other statically linked binaries from our base system, to become dynamically linked. At least I added a knob for building toolchain dynamic, but avoided the fight of making this default. Why do things by hand when there are good tools? Note ... as it was usually done forever doesn't contain a good argument, and compilers and linkers on other platforms have been doing it like this for an awfully long time. Adding the flags has a benefit in the case where there are many functions in a source file and minimal cost when everything is perfect. Not having the flags means paying a bigger price when things are not perfect. And things are very rarely perfect. Having the structure of your source code driven by link-time considerations when there is a choice seems silly to me. Larger source files gives the compiler more scope for optimisation, and you can structure the code in a way useful to people working in the codebase. If you have a moral argument about how code should be structured, I think that is separate discussion. Adding the flags has a benefit, regardless of how the code is structured. I can see all upside, and I am having trouble seeing a problem with adding them at all. On the static linking vs. dynamic linking argument: I am strongly on the static linking side. But that is also a different discussion. Regards, Jan Mikkelsen ___ 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: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
On Wed, Sep 18, 2013 at 05:36:40PM +1000, Jan Mikkelsen wrote: On 18/09/2013, at 4:22 PM, Konstantin Belousov kostik...@gmail.com wrote: On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote: [ ... ] Honestly, I think we can assume we'll never reach the point where all the components listed above will properly have all functions partitioned over separate compilation units. I suspect that it would make a lot of sense to at least enable these build flags for our core libraries (libc, libc++, libpthread, libcompiler_rt, libcxxrt, etc). We could also enable it on INTERNALLIBs (libraries that are not installed into /usr/lib), as for these libraries, it would of course not come at any cost. Would that sound okay? I think this is a wrong direction. First, the split should be done at the source level, as it was usually done forever. One of the offender there was you, AFAIR. Second, I would rather see init and devd, and in fact all other statically linked binaries from our base system, to become dynamically linked. At least I added a knob for building toolchain dynamic, but avoided the fight of making this default. Why do things by hand when there are good tools? Note ... as it was usually done forever doesn't contain a good argument, and compilers and linkers on other platforms have been doing it like this for an awfully long time. Tools are not good. Using of this feature locks us to the toolchain. And, the implementation of at least gc in the linker is known to be buggy even in recent binutils. Also, even perfect linker cannot always guess the correct value of garbage, so we have to hack in other direction. With the current set-up, it is easy to guarantee that some symbol is always present if other symbol is linked in. Adding the flags has a benefit in the case where there are many functions in a source file and minimal cost when everything is perfect. Not having the flags means paying a bigger price when things are not perfect. And things are very rarely perfect. Having the structure of your source code driven by link-time considerations when there is a choice seems silly to me. Larger source files gives the compiler more scope for optimisation, and you can structure the code in a way useful to people working in the codebase. If you have a moral argument about how code should be structured, I think that is separate discussion. Adding the flags has a benefit, regardless of how the code is structured. I can see all upside, and I am having trouble seeing a problem with adding them at all. On the static linking vs. dynamic linking argument: I am strongly on the static linking side. But that is also a different discussion. Yeah, make the things like nss, pam or iconv work or fully functional with the statically linked binaries first. pgp6v0lniNU29.pgp Description: PGP signature
Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
On 18 Sep 2013, at 07:22, Konstantin Belousov kostik...@gmail.com wrote: I think this is a wrong direction. First, the split should be done at the source level, as it was usually done forever. Until we are all using toolchains that support LTO (which requires importing a new linker and will make people who complain about buildworld memory usage even more unhappy), this approach will typically result in worse code being generated, as the compiler has significantly reduced scope for interprocedural analysis. One of the offender there was you, AFAIR. This is irrelevant to the discussion. Second, I would rather see init and devd, and in fact all other statically linked binaries from our base system, to become dynamically linked. At least I added a knob for building toolchain dynamic, but avoided the fight of making this default. In my (very informal) testing, a dynamically linked clang showed about a 5% slowdown over a statically linked one. Spending some time profiling rtld may let us improve this, but I suspect that people would complain if compilation suddenly got slower[1], especially if the only win is a small reduction in disk usage (which is most important on the kinds of platforms where you're not likely to be doing a lot of compilation). David [1] Note that once we have a linker that does LTO, these numbers may change, as we'd end up sharing the LLVM optimisation libraries between clang and the linker so the increased code sharing might offset the extra cost of the extra relocations. ___ 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: -ffunction-sections, -fdata-sections and -Wl,--gc-sections
On 18/09/2013, at 4:22 PM, Konstantin Belousov kostik...@gmail.com wrote: On Tue, Sep 17, 2013 at 11:45:19PM +0200, Ed Schouten wrote: [ ... ] Honestly, I think we can assume we'll never reach the point where all the components listed above will properly have all functions partitioned over separate compilation units. I suspect that it would make a lot of sense to at least enable these build flags for our core libraries (libc, libc++, libpthread, libcompiler_rt, libcxxrt, etc). We could also enable it on INTERNALLIBs (libraries that are not installed into /usr/lib), as for these libraries, it would of course not come at any cost. Would that sound okay? I think this is a wrong direction. First, the split should be done at the source level, as it was usually done forever. One of the offender there was you, AFAIR. Second, I would rather see init and devd, and in fact all other statically linked binaries from our base system, to become dynamically linked. At least I added a knob for building toolchain dynamic, but avoided the fight of making this default. Why do things by hand when there are good tools? Note ... as it was usually done forever doesn't contain a good argument, and compilers and linkers on other platforms have been doing it like this for an awfully long time. Adding the flags has a benefit in the case where there are many functions in a source file and minimal cost when everything is perfect. Not having the flags means paying a bigger price when things are not perfect. And things are very rarely perfect. Having the structure of your source code driven by link-time considerations when there is a choice seems silly to me. Larger source files gives the compiler more scope for optimisation, and you can structure the code in a way useful to people working in the codebase. If you have a moral argument about how code should be structured, I think that is separate discussion. Adding the flags has a benefit, regardless of how the code is structured. I can see all upside, and I am having trouble seeing a problem with adding them at all. On the static linking vs. dynamic linking argument: I am strongly on the static linking side. But that is also a different discussion. Regards, Jan Mikkelsen ___ 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
gnome2 build error (evolution-data-server-2.32.1_4)
Hello, I was trying to install gnome2 port but it ends up with an error
in evolution-data-server. Any clues?
=== Building for evolution-data-server-2.32.1_4
gmake[7]: Entering directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
gmake all-recursive
gmake[8]: Entering directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
Making all in libedataserver
gmake[9]: Entering directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver'
CC libedataserver_1_2_la-e-account-list.lo
CC libedataserver_1_2_la-e-account.lo
CC libedataserver_1_2_la-e-categories.lo
CC libedataserver_1_2_la-e-flag.lo
CC libedataserver_1_2_la-e-iterator.lo
CC libedataserver_1_2_la-e-list.lo
CC libedataserver_1_2_la-e-list-iterator.lo
CC libedataserver_1_2_la-e-memory.lo
e-flag.c:43:15: warning: 'g_cond_new' is deprecated [-Wdeprecated-declarations]
flag-cond = g_cond_new ();
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:277:17: note:
'g_cond_new' declared here
GCond * g_cond_new (void);
^
e-flag.c:44:16: warning: 'g_mutex_new' is deprecated [-Wdeprecated-declarations]
flag-mutex = g_mutex_new ();
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:273:17: note:
'g_mutex_new' declared here
GMutex *g_mutex_new (void);
^
e-flag.c:161:8: warning: 'g_cond_timed_wait' is deprecated
[-Wdeprecated-declarations]
if (!g_cond_timed_wait (flag-cond, flag-mutex, abs_time))
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:281:17: note:
'g_cond_timed_wait' declared here
gbooleang_cond_timed_wait (GCond *cond,
^
e-flag.c:182:2: warning: 'g_cond_free' is deprecated [-Wdeprecated-declarations]
g_cond_free (flag-cond);
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:279:17: note:
'g_cond_free' declared here
voidg_cond_free (GCond *cond);
^
e-flag.c:183:2: warning: 'g_mutex_free' is deprecated
[-Wdeprecated-declarations]
g_mutex_free (flag-mutex);
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:275:17: note:
'g_mutex_free' declared here
voidg_mutex_free(GMutex *mutex);
^
5 warnings generated.
e-account.c:214:11: error: cannot combine with previous 'type-name' declaration
specifier
gboolean bool;
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
e-account.c:214:2: warning: declaration does not declare anything
[-Wmissing-declarations]
gboolean bool;
^
e-account.c:218:8: error: expected identifier or '('
bool = (!strcmp ((gchar *)buf, true) || !strcmp ((gchar
*)buf, yes));
^
e-account.c:221:7: error: expected expression
if (bool != *val) {
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
e-account.c:222:11: error: expected expression
*val = bool;
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
e-categories.c:529:2: warning: 'g_atexit' is deprecated
[-Wdeprecated-declarations]
g_atexit (finalize_categories);
^
/usr/local/include/glib-2.0/glib/gutils.h:253:6: note: 'g_atexit' declared here
voidg_atexit(GVoidFuncfunc);
^
1 warning and 4 errors generated.
gmake[9]: *** [libedataserver_1_2_la-e-account.lo] Error 1
gmake[9]: *** Waiting for unfinished jobs
1 warning generated.
gmake[9]: Leaving directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver'
gmake[8]: *** [all-recursive] Error 1
gmake[8]: Leaving directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
gmake[7]: *** [all] Error 2
gmake[7]: Leaving directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
=== Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make[6]: stopped in /usr/ports/databases/evolution-data-server
*** Error code 1
Stop.
make[5]: stopped in /usr/ports/databases/evolution-data-server
*** Error code 1
Stop.
make[4]: stopped in /usr/ports/devel/bug-buddy
*** Error code 1
Stop.
make[3]: stopped in /usr/ports/x11-toolkits/py-gnome-desktop
*** Error code 1
Stop.
make[2]: stopped in /usr/ports/games/gnome-games
*** Error code 1
Stop.
make[1]: stopped in /usr/ports/x11/gnome2
*** Error code 1
Stop.
make: stopped in
Re: gnome2 build error (evolution-data-server-2.32.1_4)
This looks like the namespace pollution that was caused by iconv.h including
stdbool.h, which I have already fixed.
David
On 18 Sep 2013, at 14:57, Ricardo Campos Passanezi ri...@ige.unicamp.br wrote:
Hello, I was trying to install gnome2 port but it ends up with an error
in evolution-data-server. Any clues?
=== Building for evolution-data-server-2.32.1_4
gmake[7]: Entering directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
gmake all-recursive
gmake[8]: Entering directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
Making all in libedataserver
gmake[9]: Entering directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver'
CC libedataserver_1_2_la-e-account-list.lo
CC libedataserver_1_2_la-e-account.lo
CC libedataserver_1_2_la-e-categories.lo
CC libedataserver_1_2_la-e-flag.lo
CC libedataserver_1_2_la-e-iterator.lo
CC libedataserver_1_2_la-e-list.lo
CC libedataserver_1_2_la-e-list-iterator.lo
CC libedataserver_1_2_la-e-memory.lo
e-flag.c:43:15: warning: 'g_cond_new' is deprecated
[-Wdeprecated-declarations]
flag-cond = g_cond_new ();
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:277:17: note:
'g_cond_new' declared here
GCond * g_cond_new (void);
^
e-flag.c:44:16: warning: 'g_mutex_new' is deprecated
[-Wdeprecated-declarations]
flag-mutex = g_mutex_new ();
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:273:17: note:
'g_mutex_new' declared here
GMutex *g_mutex_new (void);
^
e-flag.c:161:8: warning: 'g_cond_timed_wait' is deprecated
[-Wdeprecated-declarations]
if (!g_cond_timed_wait (flag-cond, flag-mutex, abs_time))
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:281:17: note:
'g_cond_timed_wait' declared here
gbooleang_cond_timed_wait (GCond *cond,
^
e-flag.c:182:2: warning: 'g_cond_free' is deprecated
[-Wdeprecated-declarations]
g_cond_free (flag-cond);
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:279:17: note:
'g_cond_free' declared here
voidg_cond_free (GCond *cond);
^
e-flag.c:183:2: warning: 'g_mutex_free' is deprecated
[-Wdeprecated-declarations]
g_mutex_free (flag-mutex);
^
/usr/local/include/glib-2.0/glib/deprecated/gthread.h:275:17: note:
'g_mutex_free' declared here
voidg_mutex_free(GMutex *mutex);
^
5 warnings generated.
e-account.c:214:11: error: cannot combine with previous 'type-name'
declaration specifier
gboolean bool;
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
e-account.c:214:2: warning: declaration does not declare anything
[-Wmissing-declarations]
gboolean bool;
^
e-account.c:218:8: error: expected identifier or '('
bool = (!strcmp ((gchar *)buf, true) || !strcmp ((gchar
*)buf, yes));
^
e-account.c:221:7: error: expected expression
if (bool != *val) {
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
e-account.c:222:11: error: expected expression
*val = bool;
^
/usr/include/stdbool.h:37:14: note: expanded from macro 'bool'
#define bool_Bool
^
e-categories.c:529:2: warning: 'g_atexit' is deprecated
[-Wdeprecated-declarations]
g_atexit (finalize_categories);
^
/usr/local/include/glib-2.0/glib/gutils.h:253:6: note: 'g_atexit' declared
here
voidg_atexit(GVoidFuncfunc);
^
1 warning and 4 errors generated.
gmake[9]: *** [libedataserver_1_2_la-e-account.lo] Error 1
gmake[9]: *** Waiting for unfinished jobs
1 warning generated.
gmake[9]: Leaving directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1/libedataserver'
gmake[8]: *** [all-recursive] Error 1
gmake[8]: Leaving directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
gmake[7]: *** [all] Error 2
gmake[7]: Leaving directory
`/usr/obj/usr/ports/databases/evolution-data-server/work/evolution-data-server-2.32.1'
=== Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
Stop.
make[6]: stopped in /usr/ports/databases/evolution-data-server
*** Error code 1
Stop.
make[5]: stopped in /usr/ports/databases/evolution-data-server
*** Error code 1
Stop.
make[4]: stopped
Re[2]: ZFS secondarycache on SSD problem on r255173
The attached patch by Steven Hartland fixes issue for me too. Thank you! --- Исходное сообщение --- От кого: Steven Hartland kill...@multiplay.co.uk Дата: 18 сентября 2013, 01:53:10 - Original Message - From: Justin T. Gibbs --- Дмитрий Макаров ___ 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: libreoffice build error
On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. signature.asc Description: PGP signature
Re: libreoffice build error
On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org wrote: On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. This field is present in newer versions of the ABI spec and is also there in new versions of libsupc++. It's required for implementing C++11 dependent exceptions. It shouldn't matter for code that doesn't allocate the structure (and nothing outside of libsupc++ / libcxxrt should be allocating them), because these structures are always passed around by pointers to their ends (where the _Unwind_Exception structure lives). David ___ 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: libreoffice build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 12:39:46 -0400, David Chisnall wrote: On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org wrote: On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. This field is present in newer versions of the ABI spec and is also there in new versions of libsupc++. It's required for implementing C++11 dependent exceptions. It shouldn't matter for code that doesn't allocate the structure (and nothing outside of libsupc++ / libcxxrt should be allocating them), because these structures are always passed around by pointers to their ends (where the _Unwind_Exception structure lives). Ah, I see. Now I wrote a proper fix and it looks very promising. :-) Thanks, guys! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSOeDZAAoJECXpabHZMqHOL58IALyk+dvTnWqga4RQJIXA2bUC JFxqyK1CPsJSLk/IKhxGP0TFxll/oJhmCuPU9hwxqhlzrUBc+mvCE4ms0pLF/g3u DZccKQKB20xGmLRSjRIF0ErfM6vL/mpRcSGQK3kztTwTpquk9PcImLDIxs4Q8Jw8 76fvj83TYleRNNyQy6L0nrfmIRlAPcJlGc7mcbWghx0AqttVpmDTmbyXihDwlOJf fe05PNTJv6IJqMPvzf/3gr7D9MmLsZlZbOpwJgPIMCGXHbLZSVMixMs/WvzzdaSp nuCF+JDt1I9sG2eCQSkmvgQe71l1/IMW5b7sPxiOGfE6EgiUFWDtBUsAwIeAHmo= =WgDa -END PGP SIGNATURE- ___ 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: libexecinfo?
On Wed, Sep 18, 2013 at 04:57:35PM +, Walter Hurry wrote: We had a recent issue with libiconv now being included in base, thus rendering the port superfluous. Does a similar situation exist with libexecinfo? I don't seem to need the port on on 10.0-ALPHA1 r255587, and htop and ruby both build quite happily without it. The library is /usr/lib/libexecinfo.so.1. libexecinfo in base is exactly the same as the on from ports, so it should be a change that doesn't require any manual operations. regards, Bapt pgpB2Sr7_laQj.pgp Description: PGP signature
libexecinfo?
We had a recent issue with libiconv now being included in base, thus rendering the port superfluous. Does a similar situation exist with libexecinfo? I don't seem to need the port on on 10.0-ALPHA1 r255587, and htop and ruby both build quite happily without it. The library is /usr/lib/libexecinfo.so.1. ___ 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: libexecinfo?
On Wed, 18 Sep 2013 19:11:50 +0200, Baptiste Daroussin wrote: On Wed, Sep 18, 2013 at 04:57:35PM +, Walter Hurry wrote: We had a recent issue with libiconv now being included in base, thus rendering the port superfluous. Does a similar situation exist with libexecinfo? I don't seem to need the port on on 10.0-ALPHA1 r255587, and htop and ruby both build quite happily without it. The library is /usr/lib/libexecinfo.so.1. libexecinfo in base is exactly the same as the on from ports, so it should be a change that doesn't require any manual operations. Ah, right. Thanks. Then I can safely do as I already have; i.e. remove the libexecinfo package and recompile those affected. This on the grounds that the fewer unnecessary ports the better, imho. ___ 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: libexecinfo?
On 18 September 2013 13:11, Baptiste Daroussin b...@freebsd.org wrote: libexecinfo in base is exactly the same as the on from ports, so it should be a change that doesn't require any manual operations. To clarify, it is not the same code, but provides exactly the same interface. The one now in base comes from NetBSD and should work on all architectures. ___ 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: libreoffice build error
On 18 Sep 2013, at 19:31, Tijl Coosemans t...@freebsd.org wrote: There are some pointers to the start such as the caughtExceptions field in struct __cxa_eh_globals and the nextException field in struct __cxa_exception itself. These are not part of the public API. David ___ 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: libreoffice build error
On 18 Sep 2013, at 19:49, David Chisnall thera...@freebsd.org wrote: These are not part of the public API. Oh. Yes it is. Ho hum... David ___ 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: libreoffice build error
On Wed, 18 Sep 2013 17:39:46 +0100 David Chisnall wrote: On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org wrote: On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. This field is present in newer versions of the ABI spec and is also there in new versions of libsupc++. It's required for implementing C++11 dependent exceptions. It shouldn't matter for code that doesn't allocate the structure (and nothing outside of libsupc++ / libcxxrt should be allocating them), because these structures are always passed around by pointers to their ends (where the _Unwind_Exception structure lives). There are some pointers to the start such as the caughtExceptions field in struct __cxa_eh_globals and the nextException field in struct __cxa_exception itself. signature.asc Description: PGP signature
10.0-ALPHA2 Now Available
The second ALPHA build of the 10.0-RELEASE release cycle is now available on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and sparc64 architectures. The 10.0-ALPHA2 builds are based on svn revision r255659 of the head/ branch. The image checksums follow at the end of this email. ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/ (or any of the FreeBSD mirror sites). Note: Because of the time difference the powerpc64 images were uploaded, there may be some delay until that has propagated to all mirrors. If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. If you would like to use SVN to do a source based update of an existing system, use the head/ branch. Please be aware that cvsup and CVS are not supported methods of updating the src/ tree. Important note to freebsd-update(8) users: freebsd-update(8) is not a supported upgrade path for the 10.0-ALPHA builds. Changes between -ALPHA1 and -ALPHA2 include: o Add -stdlib=libstdc++ to CXXFLAGS when building libstdc++ and libsupc++ with clang. o Fix an issue that caused Integrated RAID volumes on LSI mps(4) controllers to not get scanned on boot. o Fix a panic during pageout observed on some powerpc64 systems. o Import Hyper-V paravirtualized drivers from projects/hyperv branch. o Add the new iSCSI target an initiator (iscsictl(8)). o Add the vmx(4) driver to amd64 and i386 GENERIC kernels. o Various fixes to the drm/radeon driver. o Various updates to the unbound import. Checksums: amd64: SHA256 (FreeBSD-10.0-ALPHA2-amd64-bootonly.iso) = 96db67171768bfd4ff5c900b179a7316d7bbc0ab4220b4c72039fa1d0261f442 SHA256 (FreeBSD-10.0-ALPHA2-amd64-disc1.iso) = 5e904de106ab3215cd89785a3d473d631bda65abd071a84bb8be75c15f3a7bd1 SHA256 (FreeBSD-10.0-ALPHA2-amd64-memstick.img) = b5d25f03d2545894f81a1d21e946b16fc08c7547675df2578a90c4fb612c8f48 MD5 (FreeBSD-10.0-ALPHA2-amd64-bootonly.iso) = aa428e018d1668bd55061f6c9853ad44 MD5 (FreeBSD-10.0-ALPHA2-amd64-disc1.iso) = a1b9358595009eea6ceb6feaee07351c MD5 (FreeBSD-10.0-ALPHA2-amd64-memstick.img) = 6d0a69d51fef3b45d0d8caf55c5f630f i386: SHA256 (FreeBSD-10.0-ALPHA2-i386-bootonly.iso) = 1cceb94d074d85604fa6708c9c84342dbb82f114633eb5ace14e119176acc9fe SHA256 (FreeBSD-10.0-ALPHA2-i386-disc1.iso) = 88c9202b4c8ff0ea0a84c6304cc34dcad3ff410c51b4fb670b18262bd87cc960 SHA256 (FreeBSD-10.0-ALPHA2-i386-memstick.img) = 1cafa1a0d93a22f50f74b7d53592ad7c0d2a6464e35b437c055f0c215f366939 MD5 (FreeBSD-10.0-ALPHA2-i386-bootonly.iso) = 5535bd009a5dcb92b0ddffaedf57da58 MD5 (FreeBSD-10.0-ALPHA2-i386-disc1.iso) = 0f308faf5df967cffe18aef588aa9be4 MD5 (FreeBSD-10.0-ALPHA2-i386-memstick.img) = 4bb1c75340df7bd50d411214b828440a ia64: SHA256 (FreeBSD-10.0-ALPHA2-ia64-bootonly.iso) = 417c49885967b1b04c236cb6931031e1697fe1268d4c091e5659ac7c3db1f609 SHA256 (FreeBSD-10.0-ALPHA2-ia64-disc1.iso) = cb7b5048acd936c79686736e6081d7683e9c94505178b9843ba43b28e81376ec SHA256 (FreeBSD-10.0-ALPHA2-ia64-memstick.img) = 65131f70eb43820efb331e95d42096db65177ea03cfe29ef5e539b79d32d74f6 MD5 (FreeBSD-10.0-ALPHA2-ia64-bootonly.iso) = 75b00d08621ecde735a742a55530a909 MD5 (FreeBSD-10.0-ALPHA2-ia64-disc1.iso) = 249306e3bdaf85a984b81b18c667c4ab MD5 (FreeBSD-10.0-ALPHA2-ia64-memstick.img) = 28aec4b95255530b8c8da04db343630f powerpc: SHA256 (FreeBSD-10.0-ALPHA2-powerpc-bootonly.iso) = 29979ce242c27e1aaacc98fb6144c45a78cecb45bfd212fd0ef3526aa33ab386 SHA256 (FreeBSD-10.0-ALPHA2-powerpc-disc1.iso) = d8464bc048d436fed5e8b7d761dc6786d60b002bed7b3e042da0112a1904a373 SHA256 (FreeBSD-10.0-ALPHA2-powerpc-memstick.img) = 9c5e3c5808e5cf4ab32b77b8c84887bc8e5d8fc41a127233effa5d210c1bbff9 MD5 (FreeBSD-10.0-ALPHA2-powerpc-bootonly.iso) = 1f77ff135d0e2b87cd8b0a13016af88e MD5 (FreeBSD-10.0-ALPHA2-powerpc-disc1.iso) = a2fa373cd44a92edcd54ec5cabacb4f7 MD5 (FreeBSD-10.0-ALPHA2-powerpc-memstick.img) = 0528f0a825eca7b5adbef7b755d2e4b2 powerpc64: SHA256 (FreeBSD-10.0-ALPHA2-powerpc-powerpc64-bootonly.iso) = e15dc7a9acc467a0f168eb3468c3f3d3b5efb95775440137d8c00a116f3a5084 SHA256 (FreeBSD-10.0-ALPHA2-powerpc-powerpc64-disc1.iso) = 05b0ab08d2b9afb3375e4cf1494cadc004be884a4975bf260ffdc58999b7505e SHA256 (FreeBSD-10.0-ALPHA2-powerpc-powerpc64-memstick.img) = ad1b6cd82d6de8ad64a1ae81aa6cbda513e0323fbb3c92da41032c424bc89cfb MD5 (FreeBSD-10.0-ALPHA2-powerpc-powerpc64-bootonly.iso) = b35b01668d9c89546aa509ccaa7f4a5f MD5 (FreeBSD-10.0-ALPHA2-powerpc-powerpc64-disc1.iso) = 02d3f48b3a7c55e0ef34ce8a6f0e08cb MD5 (FreeBSD-10.0-ALPHA2-powerpc-powerpc64-memstick.img) = 392bbb412630eb154583c7c507f5cd4f sparc64: SHA256 (FreeBSD-10.0-ALPHA2-sparc64-bootonly.iso) = 849769e15cfa639d152a0bf39ac338c4062e0326067f1b13a9f657134bf57153
Re: 10.0-ALPHA2 Now Available
On 2013.09.18 14:36, Glen Barber wrote: Changes between -ALPHA1 and -ALPHA2 include: ... o Import Hyper-V paravirtualized drivers from projects/hyperv branch. These were merged in r255524 and are in -ALPHA1 (I am currently using them). Or has something changed with them? ___ 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: 10.0-ALPHA2 Now Available
On Wed, Sep 18, 2013 at 02:50:10PM -0500, Andrew Berg wrote: On 2013.09.18 14:36, Glen Barber wrote: Changes between -ALPHA1 and -ALPHA2 include: ... o Import Hyper-V paravirtualized drivers from projects/hyperv branch. These were merged in r255524 and are in -ALPHA1 (I am currently using them). Or has something changed with them? They were not available in the 10.0-ALPHA1 ISOs, which were based on svn revision r255501. Glen pgp2gnFw93YR8.pgp Description: PGP signature
Re: libreoffice build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 14:51:20 -0400, David Chisnall wrote: On 18 Sep 2013, at 19:49, David Chisnall thera...@freebsd.org wrote: These are not part of the public API. Oh. Yes it is. Ho hum... It seems it's removed from GCC because it broke OpenOffice.org. 8-) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732 http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=143170 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSOgkeAAoJECXpabHZMqHOlcwIALxc3r7H3Ocj7TPOG41itms6 +pmquUmLCb6f5OR6vgbgMTdAiL2olOyKrMgOUAt/+yWtpmbgZ0pgN5iOEf4Jdh5c u31q+YtxSMlYOVDjRnj30IGaYMrUXb+mU7Fq/+SHdSeI+obYn6JLZX9aECdBtKmM tI9Jfvx6KLgq4YQyFpWsBZEMeXhH8HBpcZZUtlOE4g4V7SumkZe9TbK7N+vIQYpO NJBGRlHn6RKQ25xU0Ar5FlB+nTcSIMRn/Moc/g9C3oKDk4jeVdsj8ZWsVTZvzgoL Jo7kTPSpNnDNW68PTLm3h4xd+30zs0n4qFtW5cSbeai9IfPt9MpzzqxCmbb1DtU= =eDVE -END PGP SIGNATURE- ___ 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: 10.0-ALPHA2 Now Available
Em 18/09/13 16:55, Glen Barber escreveu: On Wed, Sep 18, 2013 at 02:50:10PM -0500, Andrew Berg wrote: On 2013.09.18 14:36, Glen Barber wrote: Changes between -ALPHA1 and -ALPHA2 include: ... o Import Hyper-V paravirtualized drivers from projects/hyperv branch. These were merged in r255524 and are in -ALPHA1 (I am currently using them). Or has something changed with them? They were not available in the 10.0-ALPHA1 ISOs, which were based on svn revision r255501. Glen Hi Glen, What svn revision ALPHA2 was based? Thanks Gondim ___ 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: 10.0-ALPHA2 Now Available
On Wed, Sep 18, 2013 at 06:15:22PM -0300, Marcelo Gondim wrote: Em 18/09/13 16:55, Glen Barber escreveu: On Wed, Sep 18, 2013 at 02:50:10PM -0500, Andrew Berg wrote: On 2013.09.18 14:36, Glen Barber wrote: Changes between -ALPHA1 and -ALPHA2 include: ... o Import Hyper-V paravirtualized drivers from projects/hyperv branch. These were merged in r255524 and are in -ALPHA1 (I am currently using them). Or has something changed with them? They were not available in the 10.0-ALPHA1 ISOs, which were based on svn revision r255501. Glen Hi Glen, What svn revision ALPHA2 was based? In the announcement: The 10.0-ALPHA2 builds are based on svn revision r255659 of the head/ branch. Glen pgpDo1GbmZEBL.pgp Description: PGP signature
Re: Shuttle DS47 - Realtek RT 8111G
+#define RL_HWREV_8168G_00x4c00 +#define RL_HWREV_8168G_10x4c10 I don't know exact model number for these MACs but it may be 8168G. The Shuttle DS47 is 0x4c00 But it looks like that this changes are not in Alpha2. I get still the Message: re0: Unknown H/W revision: 0x4c00 device_attach: re0 attach returned 6 g. thomas ___ 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: libreoffice build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 13:20:27 -0400, Jung-uk Kim wrote: 2013년 9월 18일 13:20, Jung-uk Kim 쓴 글: On 2013-09-18 12:39:46 - -0400, David Chisnall wrote: On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org wrote: On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. This field is present in newer versions of the ABI spec and is also there in new versions of libsupc++. It's required for implementing C++11 dependent exceptions. It shouldn't matter for code that doesn't allocate the structure (and nothing outside of libsupc++ / libcxxrt should be allocating them), because these structures are always passed around by pointers to their ends (where the _Unwind_Exception structure lives). Ah, I see. Now I wrote a proper fix and it looks very promising. :-) Committed: http://svnweb.freebsd.org/changeset/ports/327589 Thanks! Jung-uk Kim * PS: IMHO, the ABI compatibility issue must be fixed before 10.0. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSOj6JAAoJECXpabHZMqHOlhgIAJg0fAXSLdqR+otyUrvgcfDg fuyYMfbcaVk1yGdPuUwppFb8/hZCP0YDKRCf8JmCpisz5yEcUTQYCVmvWCfjBMTa 2Caelx2Cof2ao6o4IAaDd+qVP16Mdio3e8iAb2Kh8tbj08eLIpn5GvmEOOkNGnVN HYAONN8e5x3PJN7N+vWcNR1uYw1PZHww44KImZeQ7ejbWQwE28NBbkCwLeddB4he bafcFPXJccngoW2c9RUIm81sRycZP5vP9dwhJicBHUEK46/x0TW0SQRavH5d0Wnx E4FxksUen9lQOYtbwFPEfDTH4NnHB+zlwA7SwQgqGFXHqOBn81r3+YTzNmH4rd0= =t0tP -END PGP SIGNATURE- ___ 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
Intel HD5000 graphics no /dev/dri
Hi It looks like HD5000 should be supported but I can't get it to work on the new MacBook Air. Attached the log which will show that there is no /dev/dri device. I compiled drivers and libraries the same way as I've done on HD4000 (Panasonic laptop) which works just fine (except switching to console, of course). Has anyone been successful with the HD5000? -- Johannes Lundberg Project leader and lead developer of Mirama OS (previously Viking OS) BRILLIANTSERVICE CO., LTD. My blog http://brilliantobjc.blogspot.com Mirama homepage http://www.brilliantservice.co.jp/viking/ bloghttp://hmdviking.blogspot.jp Company homepage http://www.brilliantservice.co.jp Xorg.0.log Description: Binary data ___ 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: Xorg-Radeon
On 9/17/13 9:11 PM, Jean-Sébastien Pédron wrote: On 17.09.2013 14:51, ajtiM wrote: I bult Xorg on iMc, Radeon HD 4850 with ddvd support and starts works :). The problem is when I exit it stay in black screen. There are no errors in Xorg.log. This is a know issue: our current console implementation, syscons, doesn't know about KMS (the new way to driver video cards from the kernel, not from X.Org itself). Therefore, once you start X.Org, the console can't use the display anymore, neither during your X session using Ctrl-Alt-Fx, nor after you exit from X.Org. However, even if your screen is blank after X exit, the computer doesn't crash and can be used remotely. This also means you don't have to force a shutdown: a short press on the power button will shut down the computer properly. it should be possible for the vga driver to issue a vga reset to the device.. I believe there was a standard reset instruction in the original VGA design. Every device since hten should have copied it. even if they disagree about everything else. ___ 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
what is the status of KMS support in newcons?
Hello all, I was just wondering what the status of KMS support with newcons is? About 6 weeks ago I got some help on x11@ and much was said about KMS (and the lack of support for the 'newer' Haswell graphics). somebody mentioned that one of the problems where the console goes away once you fire up X was that the console driver didn't support KMS, so you could never really successfully alt-Ctrl-bksp and kill X (or exit cleanly) and get back to your VT. Word was said that this problem was being worked on and hopefully would get brought in towards the tail end of august. So, am just wondering what the status of that project is? thanks, -Jr ___ 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
