kernel crash
Hi, When I try to mount ntfs the system crashes. Here is my last crash log www.pastebin.ca/2040170 And I can not mount DVDRW. I have searched thru mailing archives and have tried several settings but it hasnt work for me as yet. Best, Dave
Re: Compiling with gcc -march ix86
Thanks. It worked, but it didn't solve the linking problem. A forum was reporting that compiling with -march set to something newer than i386 would solve the problem. I tried instead to undefine HAVE_GCC_ATOMICS in the autotools scripts and then it linked. I'm reporting for logging purpose, if of any interest. It seems that gcc atomicity is not properly implemented in BSD variants. The autoconf generates this: int foo1; int foo2 = __sync_fetch_and_add(foo1, 1); It compiles with success, so autoconf flags gcc atomicity as supported. But while linking, I'm getting errors that tells that the function __sync_fetch_and_add is undefined. I don't even find where it is declared, neither in Asterisk sources nor DFBSD includes. SR Le 2011-01-04 11:37, Oliver Fromme a écrit : Stephane Russell sruss...@prodigeinfo.com wrote: Don't work, unfortunatly. $ setenv UNAME_M i686 $ uname -m i386 $ echo $UNAME_M i686 The flags are lower-case. sh UNAME_m=i868 uname -m i868 Best regards Oliver
Comments on pkgsrc and DragonFly
While porting programs to DragonFly, I had these issues (which are not
bugs):
- BSD is undefined in DragonFly, this isn't working:
#if (defined(BSD) BSD = 199306)
Some code might expect this to work for a BSD variant.
- In many autoconf scripts, BSD variants are grouped this way:
case ${OSARCH} in
*BSD)
or
case $uname in
*BSD*)
both are excluding DragonFly, since uname -s return DragonFly and
OSARCH is usually set to the same value. I can solve this by redefining
OSARCH variable and UNAME_s shell variable as DragonFlyBSD, which
makes less work to do. But it doesn't seem very clean to me, so I'm not
using it. But it does mean that choosing FreeBSD as build type won't
necessarly mean no changes required on the autotool scripts.
- Some programs are compiling successfully by defining FreeBSD as build
type. Is DragonFly kept close as possible to FreeBSD on purpose or
should we expect this to be a vanishing legacy?
Official positions here will me help me knowing what to expect while
porting.
Thanks,
SR
Re: Comments on pkgsrc and DragonFly
both are excluding DragonFly, since uname -s return DragonFly and OSARCH is usually set to the same value. I can solve this by redefining OSARCH variable and UNAME_s shell variable as DragonFlyBSD, which makes less work to do. But it doesn't seem very clean to me, so I'm not using it. But it does mean that choosing FreeBSD as build type won't necessarly mean no changes required on the autotool scripts. - Some programs are compiling successfully by defining FreeBSD as build type. Is DragonFly kept close as possible to FreeBSD on purpose or should we expect this to be a vanishing legacy? Official positions here will me help me knowing what to expect while porting. Thanks, SR Vanishing legacy, never depend on it. Sam
Re: Comments on pkgsrc and DragonFly
On Fri, Jan 07, 2011 at 03:03:58PM -0500, Stephane Russell wrote:
While porting programs to DragonFly, I had these issues (which are not
bugs):
- BSD is undefined in DragonFly, this isn't working:
#if (defined(BSD) BSD = 199306)
Never saw this one.
All tests I encountered in third-party software were looking for full OS
names or OS-specific defines like __FreeBSD__ or irix
- In many autoconf scripts, BSD variants are grouped this way:
case ${OSARCH} in
*BSD)
case $uname in
*BSD*)
both are excluding DragonFly, since uname -s return DragonFly and
These are a pain, but I don't think they are so pervasive; Darwin is
also considered as a BSD system and has the same problem here.
In all cases I've seen, it was fixed with a new test checking for the
full OS name:
case ${OSARCH} in
*BSD)
blah
+ Darwin)
+ blah
But it does mean that choosing FreeBSD as build type won't
necessarly mean no changes required on the autotool scripts.
- Some programs are compiling successfully by defining FreeBSD as build
type. Is DragonFly kept close as possible to FreeBSD on purpose or
should we expect this to be a vanishing legacy?
This is a vanishing legacy.
I had to distinguish between FreeBSD and DragonFly when porting the jdk
In some cases, FreeBSD oriented code was failing and I had to use the
same #define directives as NetBSD or Linux.
Kde4 packages are also troublesome; if I remember correctly, they consider
DragonFly as FreeBSD and fail at some stage during the compilation.
Official positions here will me help me knowing what to expect while
porting.
When it's on a small scale, one-liner patches fit the bill and they can
be safely sent upstream:
- #ifdef __FreeBSD__
+ #if defined(__FreeBSD__) || defined(__DragonFly__)
In other cases, adding an abstraction function such as isLinuxOrBSD may
help replace a bunch of #defines.
Sometimes, the original code is really weird/non-portable and can be
safely replaced by an equivalent construct which works equally well on
all known operating systems.
This is no official position, simply my experience so far.
--
Francois Tigeot
Re: Comments on pkgsrc and DragonFly
Hi, thanks for your reply, which I read carefully.
- BSD is undefined in DragonFly, this isn't working:
#if (defined(BSD) BSD = 199306)
Never saw this one.
All tests I encountered in third-party software were looking for full OS
names or OS-specific defines like __FreeBSD__ or irix
I think it was defined originally in BSD4.4 Lite. I contacted the NetBSD
pkgsrc's team to get some informations on common BSD defines. They
pointed me here:
«To distinguish between 4.4 BSD-derived systems and the rest of the
world, you should use the following code.
#include sys/param.h
#if (defined(BSD) BSD = 199306)
/* BSD-specific code goes here */
#else
/* non-BSD-specific code goes here */
#endif
If this distinction is not fine enough, you can also test for the
following macros.
FreeBSD __FreeBSD__
DragonFly __DragonFly__
Interix __INTERIX
IRIX__sgi (TODO: get a definite source for this)
Linux linux, __linux, __linux__
NetBSD __NetBSD__
OpenBSD __OpenBSD__
Solaris sun, __sun»
Ref: http://www.netbsd.org/docs/pkgsrc/fixes.html#fixes.build.cpp
Logically, I think that if a system is not defining BSD, than it's
simply not a BSD, it's a BSD fork at most.
These are a pain, but I don't think they are so pervasive; Darwin is
also considered as a BSD system and has the same problem here.
In all cases I've seen, it was fixed with a new test checking for the
full OS name:
case ${OSARCH} in
*BSD)
blah
+ Darwin)
+ blah
Yes, not that a problem, but some common tag would useful here too, when
possible. Also, like you say, Darwin is considered a BSD, but this
doesn't say much. It tells that BSD like code might compile. NetBSD's
pkgsrc, FreeBSD's popularity and Linux's widespread innovations, might
be the only things keeping some similarities between the BSD forks.
Kde4 packages are also troublesome; if I remember correctly, they consider
DragonFly as FreeBSD and fail at some stage during the compilation.
This is not a small problem with BSD forks. Large GUI applications like
KDE gets trully functionnal only if enough people are available to work
on it. Some defaults can be chosen (ex: KDE over Gnome like they did
with DragonFly) to overcome this partly. But on the end, there's always
some fonctionnalities not working fully or periodical crashes happening.
FreeBSD is performing better here, but it comes in one «like it or not»
variant, so their work can't be shared, sadly. And I don't think that
Apple's work on Darwin is of any benefit for the BSD world. So at most,
BSD forks can only be used seriously as strong servers. That's how I'm
using dfly.
In other cases, adding an abstraction function such as isLinuxOrBSD may
help replace a bunch of #defines.
Yes, I never thought of using one define including them all. Also, a
isBSD alone would group BSD defines in the same way. That's what the
BSD define could have been useful at. Even if it would be for simple
stuff like using bcopy instead of strcpy, and other obvious BSD behaviors.
SR
Hammer Benchmark Fun
Hi, Some one send this to me http://www.phoronix.com/scan.php?page=articleitem=dragonfly_hammernum=1 only 60 days of snapshots. UFS1 implemented differently thatn UFS2. http://en.wikipedia.org/wiki/Phoronix_Test_Suite#Controversies If I posted some thing like this on the OpenBSD-misc listI would have a lot of fun ;-) Happy New Tear to all :-) Cheers --Siju
Re: kernel crash
On 07/01/11 09:00, Dragon Fly wrote: Hi, When I try to mount ntfs the system crashes. Here is my last crash log www.pastebin.ca/2040170 I'm always getting a '500 - Internal Server Error' from that link. can you please post it somewhere else? Regards, Alex
