Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT

[Pascal Hofstee]

On Thu, 20 Nov 2008 01:46:31 -
Pegasus Mc Cleaft [EMAIL PROTECTED] wrote:

 Hi everyone, 
 
 I am having difficulties rebuilding the world after some patches
 were made today. I was wondering if anyone else is experiencing the
 same troubles?
 
 ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x0 -o
 gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/lib/crt0.o
 zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No such
 file or directory *** Error code 1
 
 Stop in /usr/src/sys/boot/i386/gptzfsboot.
 *** Error code 1

I am experiencing the exact same problem with a fresh svn checkout

-- 
  Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: a question regarding sys/shm.h

[Pascal Hofstee]

On 1/31/07, Robert Watson [EMAIL PROTECTED] wrote:

If we do decide to go ahead with the ABI change, there are a number of other
things that should be done simultaneously, such as changing the uid and gid
fields to uid_t and gid_t.  I would very much like to see the ABI change
happen, and the first step (breaking out kernel from user structures) has been
done already as part of the MAC work.  The next step is to add routines that
translate internal/external formats, which isn't hard, but requires a moderate
pile of code to do (as well as great care :-).


Well .. i finally found some spare time to have a closer look at the
shm_segsz issue ... and noticed there were actually a very limited
number of direct uses of the shm_segsz struct member (26 lines in the
entire /usr/src tree)

I have attached a patchset that should change shm_segsz to size_t.
There were however 2 to 3 locations all regarding compat code (ibcs2,
svr4 and COMPAT_43) where i opted to stay on the clear side and not
touch anything, the rest was fairly straightforward as should be
obvious from the diff. I checked to make sure no function prototypes
changed anywhere.

Please have a look at the attached patch (available at
http://callisto.offis.uni-oldenburg.de/shm_segsz-int2size_t.diff in
case the attachment gets stripped off by the mailinglist software) and
provide any feedback where appropriate.

--
 Pascal Hofstee
diff -rwuBb src.ref/lib/libc/sys/shmctl.2 src/lib/libc/sys/shmctl.2
--- src.ref/lib/libc/sys/shmctl.2	Thu Feb 15 09:55:01 2007
+++ src/lib/libc/sys/shmctl.2	Thu Feb 15 09:56:49 2007
@@ -100,7 +100,7 @@
 .Bd -literal
 struct shmid_ds {
 struct ipc_perm shm_perm;   /* operation permission structure */
-int shm_segsz;  /* size of segment in bytes */
+size_t  shm_segsz;  /* size of segment in bytes */
 pid_t   shm_lpid;   /* process ID of last shared memory op */
 pid_t   shm_cpid;   /* process ID of creator */
 short   shm_nattch; /* number of current attaches */
diff -rwuBb src.ref/sys/compat/freebsd32/freebsd32_misc.c src/sys/compat/freebsd32/freebsd32_misc.c
--- src.ref/sys/compat/freebsd32/freebsd32_misc.c	Thu Feb 15 09:49:53 2007
+++ src/sys/compat/freebsd32/freebsd32_misc.c	Thu Feb 15 09:59:05 2007
@@ -1445,7 +1445,7 @@
 };
 struct shmid_ds32 {
 	struct ipc_perm32 shm_perm;
-	int32_t		shm_segsz;
+	size_t		shm_segsz;
 	int32_t		shm_lpid;
 	int32_t		shm_cpid;
 	int16_t		shm_nattch;
diff -rwuBb src.ref/sys/compat/linux/linux_ipc.c src/sys/compat/linux/linux_ipc.c
--- src.ref/sys/compat/linux/linux_ipc.c	Thu Feb 15 09:49:53 2007
+++ src/sys/compat/linux/linux_ipc.c	Thu Feb 15 10:03:43 2007
@@ -187,7 +187,7 @@
 
 struct l_shmid_ds {
 	struct l_ipc_perm	shm_perm;
-	l_int			shm_segsz;
+	l_size_t		shm_segsz;
 	l_time_t		shm_atime;
 	l_time_t		shm_dtime;
 	l_time_t		shm_ctime;
diff -rwuBb src.ref/sys/sys/shm.h src/sys/sys/shm.h
--- src.ref/sys/sys/shm.h	Thu Feb 15 09:52:13 2007
+++ src/sys/sys/shm.h	Thu Feb 15 10:14:56 2007
@@ -77,7 +77,7 @@
 
 struct shmid_ds {
 	struct ipc_perm shm_perm;	/* operation permission structure */
-	int shm_segsz;	/* size of segment in bytes */
+	size_t  shm_segsz;	/* size of segment in bytes */
 	pid_t   shm_lpid;   /* process ID of last shared memory op */
 	pid_t   shm_cpid;	/* process ID of creator */
 	short		shm_nattch;	/* number of current attaches */
diff -rwuBb src.ref/tools/regression/sysvshm/shmtest.c src/tools/regression/sysvshm/shmtest.c
--- src.ref/tools/regression/sysvshm/shmtest.c	Thu Feb 15 09:49:36 2007
+++ src/tools/regression/sysvshm/shmtest.c	Thu Feb 15 10:22:24 2007
@@ -247,8 +247,8 @@
 	sp-shm_perm.cuid, sp-shm_perm.cgid,
 	sp-shm_perm.mode  0777);
 
-	printf(segsz %lu, lpid %d, cpid %d, nattch %u\n,
-	(u_long)sp-shm_segsz, sp-shm_lpid, sp-shm_cpid,
+	printf(segsz %zu, lpid %d, cpid %d, nattch %u\n,
+	sp-shm_segsz, sp-shm_lpid, sp-shm_cpid,
 	sp-shm_nattch);
 
 	printf(atime: %s, ctime(sp-shm_atime));
diff -rwuBb src.ref/usr.bin/ipcs/ipcs.c src/usr.bin/ipcs/ipcs.c
--- src.ref/usr.bin/ipcs/ipcs.c	Thu Feb 15 09:49:15 2007
+++ src/usr.bin/ipcs/ipcs.c	Thu Feb 15 10:20:27 2007
@@ -439,7 +439,7 @@
 		kshmptr-u.shm_nattch);
 
 	if (option  BIGGEST)
-		printf( %12d,
+		printf( %12zu,
 		kshmptr-u.shm_segsz);
 
 	if (option  PID)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: a question regarding sys/shm.h

[Pascal Hofstee]

On Thu, 2007-02-15 at 13:41 +, Robert Watson wrote:
 Unfortunately, things are a bit more tricky.  The problem is not so much the 
 API, where converting size_t/int is a relative non-event, rather, the ABI.  
 By 
 changing the size of a field in a data structure, you may change the layout 
 of 
 the structure, and hence the offset of other fields.  This offset information 
 is compiled into binaries that access the structure -- hence being part of 
 the 
 ABI.  On i386, the change from int to size_t doesn't modify the ABI, as both 
 int and size_t are 32-bit.  However, on 64-bit platforms, int is 32-bit and 
 size_t is 64-bit:
 
 sledge:/tmp uname -a
 FreeBSD sledge.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #898: Wed Feb 14 
 14:20:16 UTC 2007 [EMAIL PROTECTED]:/h/src/sys/amd64/compile/SLEDGE 
 amd64
 sledge:/tmp ./size_t
 sizeof int: 4
 sizeof size_t: 8
 
 In practice, this means that all of the later fields in the data structure 
 will be offset by 4 bytes.  This will affect any application that accesses 
 later fields in the structure but isn't recompiled.  This is why DES and I 
 have been discussing this change as requiring kernel compatibility code, 
 which 
 would provide new system calls working with the new layout, and retain old 
 system calls working with the old layout.  So we'd need to provide a new 
 shmctl() with the new structure, and an oshmctl() with the old layout.  While 
 doing that, it makes sense to do all the other ABI-related things that we'd 
 like to get out of the way, such as fixing the types in shm_perm.

I understand ... i'll leave this up to you guys .. you have obviously a
lot more hands on experience in these kinds of matters :)

-- 
  Pascal Hofstee


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: a question regarding sys/shm.h

[Pascal Hofstee]

Peter Jeremy wrote:

Whilst I agree that the Linux defn is the more sensible one, System V
IPC and common sense are not commonly found together.  Tradionally the
definition was int.  It appears that the definition changed from
int to size_t in issue 5 of the Open Group base definition but
FreeBSD has not caught up with this.

I'm not sure what plans there are to change this.  You could try
putting together a patch to address this and submitting it as a PR
(this means addressing all references to shm_segsz in the base
system, not just sys/shm.h).


First of all, thanks for the quick response. At the very least this 
sheds some light onto the history and how this situation likely came to 
pass. I'll see if i can put together a patch during the next week or so 
that would bring our definitions regarding System V IPC in synch, i'll 
also try to see if i can find additional occurances of similar 
discrepancies so these could be fixed in a single run.


Any additional sugestions/objections are always greatly appreciated.

--
  Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

a question regarding sys/shm.h

[Pascal Hofstee]

Hi,

In a recent attempt in trying to clean up some compiler warnings in a 
GNUstep related project i came upon a case where the FreeBSD datatypes 
seemed to disagree with the Linux ones. Though this in itself is not 
unusual i do wonder if in this case the Linux definition isn't the more 
proper one.


The definition in question is inside sys/shm.h and involves
struct shmid_ds.shm_segsz which seems to be defined as int whereas 
Linux defines this as size_t.


I understand these definitions are usually platform dependent but am 
wondering if Linux's size_t wouldn't be a more proper type for this 
field .. and if it would make sense to perhaps synchronize our datatypes 
used here with those used by Linux?



With kind regards,
--
  Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: libarchive vs. libtool

[Pascal Hofstee]

On Thu, 2005-10-13 at 08:17 -0700, Tim Kientzle wrote:
 Tim Kientzle wrote:
Log:
1) Use GNU libtool to build shared libraries on non-FreeBSD
   systems (or on FreeBSD systems when using ports). 
2) Overhaul the versioning logic.  
 
 Does anyone on this list think they understand libtool?
 
 I've been talking to someone using Debian who is trying
 to figure out why Debian produces a libarchive.so.1.2.36
 and FreeBSD produces a libarchive.so.3 from the exact
 same build system.
 
 The discussion of version numbering in info libtool
 is quite baffling.

The problem lies in the fact that somewhere somehow the libtool people
apparently thought it would be funny to make the way the library version
numbering works FreeBSD different from the way they do it on Linux. (At
least that's my understanding of the matter).

You may want to check the freebsd-gnome@ list and do a search for
ltverhack. It is my understanding that it is the intention to have this
bogon fixed in ports post 6.0.

-- 
Pascal Hofstee [EMAIL PROTECTED]

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: libmap.conf: mapping directories?

[Pascal Hofstee]

On Sat, 2005-09-03 at 01:01 +0300, Vladimir Kushnir wrote:
 Hi all,
[snip]
 One way: to completely remove RPATH (with chrpath, for example - BTW, this 
 is nice enough utility but to make it work with 32-bit objects one has to 
 use some workarounds). It's not always convenient, though. Much, much better 
 it would be to place ALL of ia32 compat stuff into something like 
 /compat/freebsd32 like we do it for Linux stuff, but somehow nobody seems 
 to be even remotely interested. And the last way I see (a workaround as 
 well but hey, it's better than nothing at all) would be $SUBJECT. So my 
 question is: is it possible to map, say, /usr/local/lib to 
 /usr/local/lib32 and if yes how do I do it?

There is actually an effort underway right now to make happen exactly
what you suggested: making a /compat/ia32 available with a
freebsd32-syscall table similarly to how we treat Linux.

The last word i got from the main person involved here is they
discovered a few bugs they're trying to iron out at the moment.

The person who can tell you more about that and i am sure would be
thrilled to receive additional testing support goes by the name of
Willow` on ##FreeBSD on the FreeNode IRC-network. Feel free to drop by
sometime.

-- 
Pascal Hofstee [EMAIL PROTECTED]

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Locating obsolete ports distfiles

[Pascal Hofstee]

On Mon, 2005-08-22 at 14:36 +1000, Peter Jeremy wrote:
 I currently have just over 8GB is /usr/ports/distfiles.  Some of these
 files are more than 10 years old and long obsolete.  Does anyone have
 any suggestions on how to identify which files are no longer referenced
 by current ports?
 
 Doing a 'make checksum' on every installed port and then looking at
 the atimes is one approach but this doesn't handle:
 - ports that I don't currently have installed but might need
 - ports installed on systems that mount /usr/ports readonly

sysutils/portupgrade (specifically .. portsclean -D)

-- 
Pascal Hofstee [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GNUstep and libkvm

[Pascal Hofstee]

On Mon, 24 Jan 2005 09:37:00 +0200, Peter Pentchev [EMAIL PROTECTED] wrote:
 On Sun, Jan 23, 2005 at 01:17:31AM -0800, Pascal Hofstee wrote:
 It didn't make it through this time, either.  Note that the FreeBSD
 mailing list manager rejects attachments of certain types, so if you are
 sending a C source file as, say, application/octet-stream, it *will* be
 stripped from the message before it makes it to the list.  Best use
 text/plain for patches and source files.

Hmmm .. it was a simple tar.gz file ...
Anyways .. i put my kvmtest up on the server of a friend of mine ... 

http://netherite.student.utwente.nl/~daeron/kvmtest.tar.gz

You should be able to fetch it from there ...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GNUstep and libkvm

[Pascal Hofstee]

On Thu, 6 Jan 2005 22:05:31 -0800, Pascal Hofstee [EMAIL PROTECTED] wrote:
 Well .. i noticed that kvm_getargv indeed only seems to use /proc in
 case that apparently the commandline argument list grows beyond a
 certain size, as i have been able to establish by trial and error.

OK .. i created a small kvmtest program that mimics the behaviour of
what GNUstep is trying to do ...  and managed to trigger the exact
same problem.
So i'm at least certain now that it's not related to the use of the
GCC-extension GNUstep uses to run this code before the actual
main().

Further more detailed looking into the libkvm-code revealed that the
certain limit that triggers the /proc groveling is in fact sysctl
kern.ps_arg_cache_limit

I have tried to run my kvmtest in gdb but i am running into problems there.
a standard non-debugging built libkvm doesn't allow me to step through
the entire kvm_getargv function ... (only the entry point and as soon
as i try to step, i end up at kvm_uread which is at least several
function calls further along).

I also tried building a g -O0 version of libkvm .. but as soon as i
try to step inside kvm_getargv, gdb seems to just hang and has to be
killed to terminate.

I am fairly certain by now that kvm_getargv apparently calls kvm_uread
whenever the size of commandname + argumentlength exceeds the sysctl
kern.ps_arg_cache_limit value, and at that point obviously tries to
read its argument list from /proc.

If this in intended behaviour (and cannot be circumvented in any other
way) .. at the very least the manpage for kvm_getargv should be
updated to reflect this conditional dependency on /proc.

i have attached my kvmtest for those that would be interested in
having a look at this .. a potential side-note .. GNUstep doesn't
actually kvm_open /dev/kmem but fakes a kvm_open call using /dev/null
instead ..  i am not sure if this may be relevant though.

Any potential insight or assistence in helping me properly debug
libkvm would be appreciated.

-- 
  With kind regards,
  Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GNUstep and libkvm

[Pascal Hofstee]

OOpps .. forgot to actually attach my kvmtest.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

GNUstep and libkvm

[Pascal Hofstee]

For the last couple of days i have been looking into why the
gnustep-gui-port actually Needs procfs mounted in order to
successfully build and i managed to track the problem down to being
inside libkvm. I am however no kernel hacker and my gdb-skills have
left me hanging at a point where i simply can't manage to actually
debug the libkvm code itself. (NSProcessInfo is compiled using libkvm
instead of the procfs code)

If somebody could have a closer look at this for me ... or provide me
some more details on how i can go about actually getting gdb to let me
debug Inside libkvm so i can gather some additional details that would
be highly appreciated.

The actual nature of the problem turns out to be the following however:

GNUstep apparently uses a gcc-extension to load certain code before
the program actually reaches its main() function ... it uses this to
allow GNUstep's NSProcessInfo class to gather a program's environment
and commandline arguments before its main() routine gets a chance at
potentially clobering this information.

The function that does this +[NSProcessInfo load]  is in itself
straight C, so you shouldn't need any actual Objective-C knowledge.
(+[NSProcessInfo load] means the class-method load (indicated by the
+) of class NSProcessInfo)

The following URL is a link to the relevant revision in gnustep's
cvs-tree of the NSProcessInfo class [
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSProcessInfo.m?rev=1.101content-type=text/vnd.viewcvs-markup
]

The function-call inside the load-method that actually triggers the
/proc groveling seems to be kvm_getargv (at line 406).

According to the kvm_getprocs, kvm_getargv and kvm_getenvv only
kvm_getenvv depends on a working /proc ... however from my own
observations both kvm_getenvv and kvm_argvv return the result of
kvm_doargv() ... which under certain conditions seems to call
kvm_uread() which in turn is responsible for the observed /proc
groveling.

What i have been able to establish for any GNUstep-application so far
is that the second the size of its command + length of its argument
list (not including the whitespace between command and start of
argument list) exceeds 242 bytes ... the /proc groveling occurs ...
which most likely means the conditional under which kvm_uread is
invoked is met.

As long as the size of command + argumentlist remains below (or
equals) this 242 byte threshold .. everything works as expected.

The reason the gnustep-gui port triggers this error is because it
tries to build  documentation on default (it gets REINPLACEd from no
to yes) ... and since the commandline required to perform this action
Obviously exceeds this 242 character threshold .. experiences the
problem described above.

I guess to sum it all up it all boils down to the following question.

Is it intended that kvm_getargv() apparently has a conditional under
which it depends on the existince of a working /proc .. even though
the manpage states this condition is only present for kvm_getenvv ?

And if kvm_getargv should not depend on /proc ... how can we go about
to fixing this as this is apprently only the case for short
commandlines in our current implementation.

With Kind Regards,
  Pascal Hofstee

P.S.: This is as experienced on a recent 6.0-CURRENT system .. though
the problem is Known to exist on 5.x as well.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: GNUstep and libkvm

[Pascal Hofstee]

On Fri, 7 Jan 2005 05:19:52 +, Christian S.J. Peron [EMAIL PROTECTED] 
wrote: 
 iirc, kvm_getargv() can (and does first) use a sysctl to retrieve
 it's data.  kvm_getenvv() requires procfs because
 /proc/pid/mem is currently the more simpler to read a virtual
 memory address in the context of the process.
 
 We are looking at implementing a similar mechanism to the argv
 ps_strings for process environment to get rid of the procfs requirement.
 
 pjd has some work done on this but it has not been committed yet.
 Hope this answers your question.

Well .. i noticed that kvm_getargv indeed only seems to use /proc in
case that apparently the commandline argument list grows beyond a
certain size, as i have been able to establish by trial and error.

I guess my question is .. is kvm_getargv INTENDED to use the /proc
aproach in cases the command + argument list grows beyond a certain
size.

Because if that IS the case .. the manpage doesn't reflect this.

-- 
  With kind regards,
  Pascal Hofstee
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: pthread_mutex_trylock and glib-2

[Pascal Hofstee]

Ok ..  Got some bugzilla notifications ...and apparently this issue
has been targetted for glib-2.4.7 with keywords portability.
So i assume we'll most likely have to include my provided patch for
the glib20 port until 2.4.7 comes out and an appropriate fix will
probably have been included by then.

-- 
  Pascal Hofstee
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: pthread_mutex_trylock and glib-2

[Pascal Hofstee]

On Mon, 6 Sep 2004 15:12:08 -0700, Pascal Hofstee [EMAIL PROTECTED] wrote:
 After a few hours of digging through both the glib-2 as well as the
 beep-media-player sources i finally managed to figure out why
 beep-media-player apprently crashes on startup when using libpthread,
 but not when using libc_r.
 
 i filed a bugreport against this problem on bugzilla.gnome.org ... in
 the hope to get some feedback from glib-developers ...
 
 http://bugzilla.gnome.org/show_bug.cgi?id=152009
 
 The problem is with the actual return value of pthread_mutex_trylock
 returning EDEADLK instead of EBUSY.
 
 from what i have been able to glance from this previous discussion
 regarding this particular subject
 (http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html)
 
 pthread_mutex_trylock should behave identical to pthread_mutex_lock
 except return immediately in case of a blocking mutex, which would
 suggest EDEADLK as a possible return value.
 
 This Seems to be the current implementation of both libpthread as well
 as libthr ... with libc_r being the sole exception.
 
 The pthread_mutex_trylock manpage however does not reflect this actual
 implementation and only mentions EBUSY and EINVAL.
 
 I was wondering assuming the implementation is actually correct if
 this could be rectified in the pthread_mutex_trylock manpage ... and
 if my assumption is wrong if the implementation could be changed to
 reflect the manpage.
 
 In the former case i will have to bug the glib-devs to change the
 implementation of their pthread_mutex_trylock wrapper ... to also
 check for EDEADLK.

I am hereby including an updated
/usr/ports/devel/glib20/files/patch-gthread_gthread-posix.c

that includes the additional check for EDEADLK besides EBUSY in glib's
g_mutex_trylock_posix_impl function.

With this fix applied to my installation of glib beep-media-player now
works as expected with libpthread, and this is very likely to resolve
similar behaviour with other ports that try to use glib's threading
functions.

I CC-ed glib20 port-maintainer ([EMAIL PROTECTED]) in the hope this
(or appropriate alternative) fix makes it in time for 5.3-RELEASE.

-- 
  Pascal Hofstee


patch-gthread_gthread-posix.c
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

pthread_mutex_trylock and glib-2

[Pascal Hofstee]

After a few hours of digging through both the glib-2 as well as the
beep-media-player sources i finally managed to figure out why
beep-media-player apprently crashes on startup when using libpthread,
but not when using libc_r.

i filed a bugreport against this problem on bugzilla.gnome.org ... in
the hope to get some feedback from glib-developers ...

http://bugzilla.gnome.org/show_bug.cgi?id=152009

The problem is with the actual return value of pthread_mutex_trylock
returning EDEADLK instead of EBUSY.

from what i have been able to glance from this previous discussion
regarding this particular subject
(http://lists.freebsd.org/pipermail/freebsd-threads/2004-January/001539.html)

pthread_mutex_trylock should behave identical to pthread_mutex_lock
except return immediately in case of a blocking mutex, which would
suggest EDEADLK as a possible return value.

This Seems to be the current implementation of both libpthread as well
as libthr ... with libc_r being the sole exception.

The pthread_mutex_trylock manpage however does not reflect this actual
implementation and only mentions EBUSY and EINVAL.

I was wondering assuming the implementation is actually correct if
this could be rectified in the pthread_mutex_trylock manpage ... and
if my assumption is wrong if the implementation could be changed to
reflect the manpage.

In the former case i will have to bug the glib-devs to change the
implementation of their pthread_mutex_trylock wrapper ... to also
check for EDEADLK.

-- 
  With kind regards,
  Pascal Hofstee
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Base System libobjc

[Pascal Hofstee]

Hi,

I have been playing with GNUstep for a while now, and since CURRENT
switched their base system compiler to 3.4.2 it has always felt
somewhat superfluous to use the gcc-3.3.5 port, as far as i can tell
so far ... for basically only a shared version of libobjc.

I have since been toying around with building GNUstep from GNUstep CVS
instead of ports using my base system compiler and the base system
provided static version of libobjc and so far things are looking sweet
and things are working as expected (installed ffcall from ports and so
far that seems to be only necesarry dependency)

What i am wondering about though is the following. It seems FreeBSD
already provides a static version of libobjc in its base system, which
(i assume) automatically gets updated whenever the base system's
compiler is updated to a newer snapshot/release. What i am wondering
is if there is any specific reason why FreeBSD only provides a static
version of this library, and if that is not the case, what would it
take to make a buildworld provide a shared version of this Objective-C
runtime library ?

With kind regards,
  Pascal Hofstee
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BSD dlopen and such

[Pascal Hofstee]

On Thu, Jan 04, 2001 at 10:19:56AM -0800, Doug White wrote:
 No.  The linux compatbility is through the image activator.  The syscalls
 have to be translated, otherwise if you were running as root and loaded a
 linux lib into a freebsd binary, then that lib called fcntl(), your system
 would reboot :)

Ok ... I guess i will have to hear that blunder of mine for eternity :-))

-- 
  Pascal Hofstee   daeron @ shadowmere . student . utwente . nl 
  begin  LOVE-LETTER-FOR-YOU.TXT.vbs
 I'm a signature virus. Please copy me and help me spread.
  end


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Sticky Keys ?

[Pascal Hofstee]

Hi,

A co-worker of mine who is mobilly handicapped, uses a Windows
"Accessibillity option" called "Sticky Keys" ... so he can still operate
his keyboard normally, using ... let's call it a "straw" and his mouth.

What this does is basically the following:

- Pressing SHIFT/CONTROL/ALT once makes that key "active" until the next
  keystroke.
- Pressing SHIFT/CONTROL/ALT twice makes that key "active" until it is
  pressed a third time.

He and I have been wondering if such functionality would also be available
already or "easily" to be implemented, so he might actually be able to use
a Unix environment to work with instead of a Windows one.

-- 
  Pascal Hofstee   daeron @ shadowmere . student . utwente . nl 
  Managers know it must be good because the programmers hate it so much.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

module names

[Pascal Hofstee]

Hi,

With the recent addition of more and more KLDs to the /modules directory i
was wondering if perhaps it would be a good idea to name these modules
more consistantly:

if_*: For all network modules (done already)
ng_*: For all netgraph related modules (done already)
fs_*: For all filesystem modules
saver_* : For all screensavers (probably would prefer a shorter prefix)
emu_*   : For binary compatibilty modules like linux/ibcs2/svr4

of course this is just a suggestion ... just thought i would voice it
here.


  Pascal Hofstee - [EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: module names

[Pascal Hofstee]

On Mon, 25 Oct 1999, Chris Costello wrote:

I agree with the idea but some of the name ideas are a little
 off.  What would Vinum go under?

I also disagree with your usage of ``emu_''.  I would prefer
 ``compat_''.

I agree the names were not choosen perfectly ... I agree on compat_
the suggestions i provided were just to illustrate the idea ... in the
hopes to get some discussion and attention on the whole idea.


  Pascal Hofstee - [EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Proposal: Add generic username for 3rd-party MTA's

[Pascal Hofstee]

On Wed, 1 Sep 1999, Doug wrote:

 On Wed, 1 Sep 1999, Sheldon Hearn wrote:

  I plan to add a user ``smtp'' with UID 25 and a member of group
  ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is
  primarily for the convenience of maintainers of mail ports.
 
   Why not do this as part of the port itself, ala majordomo? That
 works just fine and is completely non-controversial because you don't get
 it unless you ask for it.

I would just liek to point out that Postfix is also doing the exact same
thing ... user postfix ... (as well as a group maildrop)


  Pascal Hofstee - [EMAIL PROTECTED]

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Proposal: Add generic username for 3rd-party MTA's

[Pascal Hofstee]

On Wed, 1 Sep 1999, Doug wrote:

 On Wed, 1 Sep 1999, Sheldon Hearn wrote:

  I plan to add a user ``smtp'' with UID 25 and a member of group
  ``mail'', for use in running non-priveledged MTA's in FreeBSD. This is
  primarily for the convenience of maintainers of mail ports.
 
   Why not do this as part of the port itself, ala majordomo? That
 works just fine and is completely non-controversial because you don't get
 it unless you ask for it.

I would just liek to point out that Postfix is also doing the exact same
thing ... user postfix ... (as well as a group maildrop)


  Pascal Hofstee - dae...@shadowmere.student.utwente.nl

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: SDL port done yet?

[Pascal Hofstee]

On Wed, 9 Jun 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

 A while ago, someone mentioned that they were partway through a port of the 
 Simple DirectMedia Layer. Has this been completed?

Basically the entire SDL library works now on my FreeBSD-3.2-STABLE box
... (as that is where I have the main developer pf the SDL-librray do the
porting)

The only problem is that the pthread_cancel functions are not in our
pthread implementation yet 


  Pascal Hofstee - dae...@shadowmere.student.utwente.nl

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: SDL port done yet?

[Pascal Hofstee]

On Wed, 9 Jun 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote:

 Hmm. Has he merged the changes into the SDL codebase yet? (what is it, 
 0.9.13). Is anyone doing anything about the pthread_cancel calls?

As far as I know the changes have been merged into the main SDL code base.
(it was basically some very minor changes to the linux-code ... with a
rewrite of the cd-audio code) ...

as far as the pthread-concel functions are concerned ... i don't really
know much about the current status on this issue.



  Pascal Hofstee - dae...@shadowmere.student.utwente.nl

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

pthread_cancel ?

[Pascal Hofstee]

Hi,

I am currently having the author of the SDL-library on my box trying to
cook up a port of the SDL-library for FreeBSD.

SDL (Simple DirectMedia Layer) is the library used by Loki Software to
build CIV:CTP

As I have seen now the entire library works perfectly ;-)

except for one thing  FreeBSD's pthread-implementation (libc_r)
doesn't seem to have the pthread_cancel  method(s) implemented .. which
make the threaded part of the library mallfunction ...

My question is if there is any likely support considdered on adding those
additional function calls to FreeBSD's PTHREAD implementation ?


  Pascal Hofstee - dae...@shadowmere.student.utwente.nl

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP--
t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+
--END GEEK CODE BLOCK--



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message