[Mono-bugs] [Bug 74698][Min] Changed - Corlib Unit tests failing / wrong runtime support on FreeBSD
Sat, 23 Apr 2005 12:35:23 -0400 (EDT)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by firstname.lastname@example.org.
--- shadow/74698 2005-04-23 11:51:06.000000000 -0400
+++ shadow/74698.tmp.10185 2005-04-23 12:35:23.000000000 -0400
@@ -1,23 +1,23 @@
-Product: Mono: Class Libraries
+Product: Mono: Runtime
+OS Details: FreeBSD
-Summary: Corlib Unit tests failing
+Summary: Corlib Unit tests failing / wrong runtime support on FreeBSD
Description of Problem:
There are a couple of tests in the corlib unit tests which I had to remove
from corlib_test.dll.sources to get the suite to run to completion here on
@@ -116,6 +116,58 @@
+------- Additional Comments From email@example.com 2005-04-23 12:35 -------
+> No warnings at all in the compilation
+You must be the only one not getting warnings when compiling mono ;-)
+or maybe we're not talking about the same thing...
+Anyway (just to be 100% sure) I'm curious if FreeBSD has support for
+some uid/grp/nam functions.
+E.g. /mono/io-layer/security.c checks for both getresuid and
+setresuid. If not supported then you should see warnings.
+ #warning getresuid not supported. WindowsImpersonationContext wont work
+ #warning setresuid not supported. WindowsImpersonationContext wont work
+E.g. /mono/metadata/security.c checks for more functions. If not
+supported then it reverts to non-thread safe versions of the same calls.
+ #warning Non-thread safe getgrgid being used!
+ #warning Non-thread safe getgrnam being used!
+ #warning Non-thread safe getpwnam being used!
+ #warning Non-thread safe getpwuid being used!
+Other similar functions are also called in security.c, if any behave
+differently in FreeBSD (than Linux) then you could get strange
+The "easy" fix is to exclude all this stuff from FreeBSD and throw
+NotSupportedException when they are called (and fix the unit tests to
+ignore this too). The "nice" way would be to find the "bad(s)" calls
+and replace them with the correct FreeBSD variant.
+Sadly I can only do the "easy" solution myself. It would be "nice" if
+you could have a look at them so we can figure the best support for