Re: [Mono-dev] Summer of Code / C++ Interop
Hi Andreas, On Thu, Apr 8, 2010 at 6:06 AM, Andreas Färber wrote: > > CSimpleClass.cs looks as if it was written manually. I see a problem with > changing C++ code there: To allow managed code to instantiate such a class, > your private struct needs to match exactly the size of the native code. If > however someone adds a private field in C++ but does not update the interop > code, it will fail. Would it be possible to leave the memory allocation to > C++ (the ABI document mentions "nw" in the name-mangling section) and in C# > just map the methods we actually want to call? > > >From my brief review of the ABI document, I think the "nw" function you mention is only defined when the "new" operator is overridden. Although, if that operator is overridden, the interop code should probably respect that and use that function to allocate the memory for the object instead of doing it manually. (I guess I'll have to add that to the TODO list :). However, I'm pretty sure that in most cases there is no such function and that, in C++, the caller usually allocates the memory when instantiating an object and passes the pointer to the constructor. This is usually pretty straightforward, since including the header includes the class definition, which defines the exact size of the class. My eventual goal is to have a tool that will parse C++ headers and generate the managed interface and struct for you. At this point, however, the interface does have to be written manually, and the struct does have to reflect the exact size of the C++ class. > For your proposed project, would you be focussing on the p/invoke ABI > infrastructure only? Any plans for SWIG-like autogeneration of the (C#) > proxy interfaces from C++ headers? And what about C++ interop inside Mono's > class libraries? > I think that, for the scope of the Summer of Code, I will focus on making the implementation of the Itanium ABI more complete. Since this is an open standard that is implemented by GCC 3.2+, and GCC is the primary C++ compiler on Mac and Linux, this will be a big step for C++ interop in Mono. Eventually, I'd like to implement a SWIG-like generation of the managed interfaces from the C++ headers like you mention, and I'd like to implement the Microsoft Visual C++ ABI as well. But it will probably be quite awhile until those features are implemented, unless I have some help :). I'm not sure what you mean by C++ interop inside Mono's class libraries. If you mean including the interop features I'm developing in the core class libraries, I'm all for it, but I guess that's up to the Mono maintainers. I really appreciate your feedback. Please let me know if I can clarify anything else for you. Cheers, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] switch gensources.sh in the 2.6 branch to /bin/sh (HEAD is /bin/sh already)
Index: mcs/tools/gensources.sh === --- mcs/tools/gensources.sh (revision 155127) +++ mcs/tools/gensources.sh (working copy) @@ -1,4 +1,4 @@ -#!/usr/bin/env bash +#!/bin/sh includefile=$1 excludefile=$2 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
On Thu, Apr 8, 2010 at 5:29 PM, Jerry Maine - KF5ADY wrote: > What does everyone think about making a new dlr script language that is > compatible with sh or bash? Maybe called sh#? I would certainly like a file- and process-oriented bash-like scripting language for dlr/clr that runs on Mac, Linux and Windows. Currently, if I write bash scripts for a project then Windows developers have to install something like cygwin, or we cook up the equivalent .bat. Bleck on the .bat. I get along with cygwin okay, but that's a heavy requirement, especially considering the installation experience. I wouldn't personally require total compatibility with sh or bash. In other words, if you did some things differently, I would still use it. For example, bash cannot make up its mind on how to end a block (fi, }, done, esac). Why not just "end" or "end foo"? The tie in with .net/mono would obviously be attractive to this group. To be fair, I have not evaluated to what extent PowerShell might already fulfill this role. Thanks for bringing this up, -Chuck ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
> What does everyone think about making a new dlr script language that is > compatible with sh or bash? Maybe called sh#? Have you considered using say zsh or ksh? I mean there are already many different shells so the question is do we really need yet another shell? On the other hand, if one wants to gradually transform Unix-like systems into Windows-like systems, then one can use the "real" thing instead. a.s. -- Apostols Syropoulos Xanthi, Greece _ Νέα Windows 7: Απλοποιήστε τις καθημερινές σας εργασίες. Βρείτε τον κατάλληλο υπολογιστή για εσάς. http://windows.microsoft.com/shop___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
On 09.04.2010 12:38, Απόστολος Συρόπουλος wrote: > On the other hand, if one wants to gradually transform Unix-like systems > > into Windows-like systems, then one can use the "real" thing instead. This is not an option because we aim to subvert Unix-like systems after all. The first goal of world's dominance is to replace all g*-tools with *# variants and call those ethical. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
> This is not an option because we aim to subvert Unix-like systems > after all. The first goal of world's dominance is to replace all > g*-tools with *# variants and call those ethical. Be my guest but remember that sh is not GNU tool! A.S. -- Apostols Syropoulos Xanthi, Greece _ Hotmail: Ισχυρό, δωρεάν email με ασφάλεια από τη Microsoft. https://signup.live.com/signup.aspx?id=60969___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
> This is not an option because we aim to subvert Unix-like systems > after all. The first goal of world's dominance is to replace all > g*-tools with *# variants and call those ethical. > On a second thought, it would be quite interesting to have to type ls# -l, dd# if=/dev/zero# etc. Not to mention that in certain cases tar# would not be functional and a newer tar# would be needed to untar# the latest tar# archive, which will be included in an executable rar# archive... A.S. -- Apostols Syropoulos Xanthi, Greece _ Το email σας και πολλά ακόμα εν κινήσει. Αποκτήστε δωρεάν το Windows Live Hotmail. https://signup.live.com/signup.aspx?id=60969___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
On 4/8/2010 8:29 PM, Jerry Maine - KF5ADY wrote: > What does everyone think about making a new dlr script language that is > compatible with sh or bash? Maybe called sh#? > I think it would be awesome. Please go get started, let me know when you have something to share :) I love bash, and being able to join bash and the BCL would be awesome. -- Jay ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Mono and the MOSA Project
On 04/07/10 Phil Garcia wrote: > Since we are implementing everything in .NET/C# we don?t need InternalCalls > to call external API bindings. In fact, the external declarations in the > source code get into the way. So we have moved the InternalCalls method > declarations into separate partial class files (for example, > String.Internal.cs). This patch allows us to compile Mono class libraries > without referencing those external methods declarations and substitute own > managed versions. I don't think that shuffling around the code like that is acceptable for us. A change that could be included would be to surround the icalls with a #if check and then you compile with that define. I suggest something like NO_ICALLS. > We had updated the Object class too, but it caused a single failed test so > we have excluded it from here. The test failed due to a change in the order > of the Object class methods. We are not sure if this is just a paranoia > check (but kumpera on IRC said "tons of user code can depend on it"). > Otherwise, all the other tests passed. We checked the new mscorlib from .NET > 4.0 through ildasm and Mono doesn't follow the same method ordering for > Object. Is the ordering of methods for the Object class really important for > Mono? If you pointed out the name of the test we could fix it to not depend on the order if it's really a bug in the test. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Mono and the MOSA Project
> If you pointed out the name of the test we could fix it to not depend on > the order if it's really a bug in the test. The failing test was: Test Case Failures: 1) MonoTests.System.Reflection.Emit.TypeBuilderTest.TestGetMethodsIncomplete_Mono : #D1 Expected string length 7 but was 8. Strings differ at index 0. Expected: "GetType" But was: "ToString" ---^ -- View this message in context: http://n4.nabble.com/PATCH-Mono-and-the-MOSA-Project-tp1755924p1819447.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Socket.BeginReceive never throw Exception
> socket.BeginReceive(receive_buffer, 0, FlockNode.buffer_size, 0, > new AsyncCallback(ReceiveDone), socket); > If the Socket gets disconnected by the remote host, > ReceiveDone is called, and EndReceive will throw a SocketException; > thus you know that your socket is now disconnected without having > to poll it. With Mono, no exception is thrown. Just to be a bit more clear about this, not only no exception is thrown, ReceiveDone isn't called either. -- View this message in context: http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1819481.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Socket.BeginReceive never throw Exception
Is there a testcase for this? This works fine for me, I'm inclined to believe there's a bug in the testcase. Alan. On Fri, Apr 9, 2010 at 4:21 PM, Stefan [At] wrote: > >> socket.BeginReceive(receive_buffer, 0, FlockNode.buffer_size, 0, >> new AsyncCallback(ReceiveDone), socket); > >> If the Socket gets disconnected by the remote host, >> ReceiveDone is called, and EndReceive will throw a SocketException; >> thus you know that your socket is now disconnected without having >> to poll it. With Mono, no exception is thrown. > > Just to be a bit more clear about this, not only no exception is thrown, > ReceiveDone isn't called either. > -- > View this message in context: > http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1819481.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Mono and the MOSA Project
On Fri, Apr 9, 2010 at 7:44 AM, Paolo Molaro wrote: > I don't think that shuffling around the code like that is acceptable for > us. A change that could be included would be to surround the icalls > with a #if check and then you compile with that define. > I suggest something like NO_ICALLS. > We originally tried that approached by surrounding the internal call declarations with #if and #endif and around the new "partial" keyword in to the class definition. But based on some feedback from Miguel that "#ifdef are a mess" (he preferred partial classes instead) and similar discussions within the MOSA team, we abandoned that approach in favor of using partial classes for separating the internal calls. With the proposed approach, the source code is less cluttered since conditional compiler directives are not needed. One beneficial side effect is we can automated more with less manual edits too. We are open to either approach, but prefer the one proposed. Phil ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gmcs stacktrace
I am trying to build 3 projects with MonoDevelop that are already building successfully in Visual Studio. The first two build successfully but one is triggering a stacktrace from gmcs. I don't believe the project code is doing anything fancy or bleeding edge. I've tried it with different versions of mono (2.4.2.3 and 2.4.4.2) to see if there were any resolved compiler errors but the same error occurred. If you have any ideas about why the compiler might be behaving in this way or strategies to find out what code it is choking on, please let me know. Thanks! Stephen /usr/bin/gmcs ... Stacktrace: at (wrapper managed-to-native) System.Type.MakeGenericType (System.Type,System.Type[]) <0x4> at (wrapper managed-to-native) System.Type.MakeGenericType (System.Type,System.Type[]) <0x> at System.Type.MakeGenericType (System.Type[]) <0x0011e> at Mono.CSharp.ConstructedType.DoResolveType (Mono.CSharp.IResolveContext) <0x000cd> at Mono.CSharp.ConstructedType.ResolveConstructedType (Mono.CSharp.IResolveContext) <0x000d9> at Mono.CSharp.ConstructedType.DoResolveAsTypeStep (Mono.CSharp.IResolveContext) <0xe> at Mono.CSharp.TypeExpr.ResolveAsTypeStep (Mono.CSharp.IResolveContext,bool) <0x00014> at Mono.CSharp.SimpleName.ResolveAsTypeStep (Mono.CSharp.IResolveContext,bool) <0x0012d> at Mono.CSharp.Expression.ResolveAsBaseTerminal (Mono.CSharp.IResolveContext,bool) <0x0002c> at Mono.CSharp.TypeContainer.GetNormalBases (Mono.CSharp.TypeExpr&) <0x0008a> at Mono.CSharp.TypeContainer.GetClassBases (Mono.CSharp.TypeExpr&) <0x0001a> at Mono.CSharp.Class.GetClassBases (Mono.CSharp.TypeExpr&) <0x00017> at Mono.CSharp.TypeContainer.DefineBaseTypes () <0x0001e> at Mono.CSharp.TypeContainer.DefineType () <0x00054> at Mono.CSharp.Class.DefineType () <0x000b5> at Mono.CSharp.RootContext.ResolveTree () <0x001ac> at Mono.CSharp.Driver.Compile () <0x0049c> at Mono.CSharp.Driver.Main (string[]) <0x0006e> -- View this message in context: http://n4.nabble.com/gmcs-stacktrace-tp1819616p1819616.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
I was working on* just this project. I toyed with the standard Ironing of the names, IronBash or maybe bash4.net. I'd love to see this too. Would be nice to use it as a drop in replacement for boot, compilation, everything. Auto generate and save an assembly... oh the possibilities. Joe *: Just initial research, nothing written. Too many things, too little time. :( > What does everyone think about making a new dlr script language that is > compatible with sh or bash? Maybe called sh#? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] sh#
Hi, We have very serious requirement for this. We tend to use it for dynamic rules / event processing. For now, we are just using Reflection, and still ne to clean runtime compilation. Any formal design will be great. Ajay -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Jerry Maine - KF5ADY Sent: Thursday, April 08, 2010 8:29 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] sh# What does everyone think about making a new dlr script language that is compatible with sh or bash? Maybe called sh#? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing DbLinq 0.20
The DbLinq[0] team is proud to announce the release of DbLinq 0.20,
following the venerable DbLinq 0.19 release from December 2009.
DbLinq is a reimplementation of System.Data.Linq.dll for use with SQL
servers in addition to Microsoft SQL Server. Support is provided for:
* Firebird [1]
* Ingres [2]
* MySQL [3]
* Oracle [4]
* PostgreSQL [5]
* SQLite [6]
* SQL Server [7]
Note that not all servers are supported equally: some tests will pass
under some database backends while failing under others. I maintain the
SQLite and SQL Server backends, while the community handles the others.
My focus for this release has been on fixing DbMetal and sqlmetal
issues. In particular, sqlmetal can now generate .dbml files.
Additionally, the CodeDom generator now works, allowing you to generate
Visual Basic .NET sources, and the older "CodeText" generator has been
deprecated (and is available via `/language:obsolete-c#`). It will be
removed in the next release.
A horrifically unreadable list of issues fixed is at the end. [8]
Enjoy!
- Jon
[0] http://code.google.com/p/dblinq2007/
[1] http://www.firebirdsql.org/
[2] http://www.ingres.com/
[3] http://www.mysql.com/
[4] http://www.oracle.com/
[5] http://www.postgresql.org/
[6] http://www.sqlite.org/
[7] http://www.microsoft.com/sqlserver/
[8] Part of the length of this is that all "inactive" and "unresponsive"
bugs were closed so that currently relevant bugs would actually be
visible at http://code.google.com/p/dblinq2007/issues/list
7
Add
MySQL 4.0 support
9
pgsqlmetal generates invalid DbType attribute for integer
34
pgsqlmetal primary key constraint
45
sqlmetal should generate table names without schemas
60
DbType attribute does not contain some clauses
67
FirstOrDefault return error
71
DbMetal & Oracle: Tables aren't loaded
73
DynamicQueryOrderBy
77
DataMembers property not implemented
78
DbLinq.Pgsql.Example.csproj contains bad project reference
79
"contains" could not parse correctly to "like"
80
left
column should be quoted
82
Possibility to have all generated classes in lowercase
83
DbLinq.Linq.DataContext' missing a constructor
86
read
blob
from
mysql?
88
MySql dbtype "TimeStamp" isn't supported by DbLinq.
90
Referenced tables more than 1 times
93
Some
LINQ
expressions an error - no such column True
94
Unable to read inherited types using DBLinq to Sqlite
96
NRE
in
QueryBuilder.Upsert.cs: GetUpsertParameters method
98
Does
dbLinq support "EntitySet"?
101
Error saving password
106
NullReferenceException during insert
107
DbMetal leaves types blank for fields generating bad code
108
DBMetal describes an unsigned integer as a signed integer
109
MySql 5 varbinary columns are undeceted
116
Unsupported types in Pgsql
117
Problems in VisualMetal generated file with Pgsql
118
DBLinq_test build fails due to missing AssemblyInfo.cs
119
System.Data.Linq missing assembly reference
120
ORA-02291:integrity constraint violated - parent key not found
123
dbmetar error with firebird sample
124
BulkInsert SqlServer fails for nullable
125
Bug
in
association creation
126
Problem in SubmitChanges() in Linux
127
Multiple associations from the same table to the same table
128
"Invalid column '{0}'" bad error
129
No
support for aggregate functions with lambdas
130
Delegate compilation error for types with nullable properties
131
An
error has occurred with Table.Max if table no record
134
Exception whith sqlite foreign key
137
Bug
requesting uuid
138
Trying to iterate through MySQL view throws an exception.
140
While running dbmetal in VS 2008 i got the Following Error
141
mediumtext MySql datatype not supported
142
Joins for more than 3 tables
143
DbMetal doesn't generate datatypes for sqlite FTS3 tables
145
mysql: unsigned float problem
148
LambdaMetaAccessor missing in DbLinq project
150
Unable to update table: SQLite error no such column: true
152
Cannot update record if primary key of table is uuid
154
DbMetal can not create the class file for Oracle 10g
155
Type
ommitted for "timestamp with time zone" column
160
Duplicate methods generated for some overloaded functions
161
"Lambda Parameter not in scope" error when calling a function
164
GetBooleanAttribute should also return true for "True"
165
northwind for mysql
170
Can't use DbMetal with port numbers
171
SqlMetal can't generate DBML files
172
ria
services
173
DbMetal generates metho
Re: [Mono-dev] [PATCH v4 4/7] io-layer: Fix process helper functions for Haiku
Looks ok.
Zoltan
On Mon, Apr 5, 2010 at 1:52 AM, Andreas Färber wrote:
> Haiku has neither makedev nor /proc. Enumerate processes, process modules
> and retrieve the process name via Kernel Kit. Fixes build on Haiku.
>
> Adjust _WAPI_PROCESS_UNHANDLED_PID_MASK to cope with Haiku's 32-bit pid_t.
> Fixes exception trying to obtain the ProcessName of pids >= 2^15.
>
> v3 -> v4:
> * Rebase against OpenBSD changes.
>
> v2 -> v3:
> * Fix get_process_name_from_proc implementation to use get_next_image_info.
> * Add new implementation of EnumProcesses.
> * Fix OpenProcess' check whether pid is available.
> * Fix _WAPI_PROCESS_UNHANDLED_PID_MASK to handle Haiku's 32-bit pid_t.
> * Fix module addresses in load_modules by considering the text segment,
> too.
> Suggested by Ingo Weinhold.
> * Add ChangeLog entry, fix file encoding.
>
> v1 -> v2:
> * Instead of providing a dummy makedev macro, avoid its use.
> * Don't try to parse /proc.
> * Add new implementations of load_modules and get_process_name_from_proc
> based on libroot's Kernel Kit, suggested by François Revol.
> ---
> mono/io-layer/ChangeLog | 14 +++-
> mono/io-layer/process-private.h |4 ++
> mono/io-layer/processes.c | 69
> +--
> 3 files changed, 83 insertions(+), 4 deletions(-)
>
> diff --git a/mono/io-layer/ChangeLog b/mono/io-layer/ChangeLog
> index bb199ba..3fed2e9 100644
> --- a/mono/io-layer/ChangeLog
> +++ b/mono/io-layer/ChangeLog
> @@ -1,3 +1,15 @@
> +2010-04-04 Andreas Färber
> +
> + * processes.c (EnumProcesses, load_modules): Add implementations
> + for Haiku. Fixes build on Haiku.
> + (OpenProcess, EnumProcessModules, get_process_name_from_proc):
> + Tweak implementations for Haiku.
> + * process-private.h: Fix _WAPI_PROCESS_UNHANDLED_PID_MASK for
> + 32-bit pids (Haiku).
> + * ChangeLog: Fix UTF-8 encoding
> +
> + Code is contributed under MIT/X11 license.
> +
> 2010-04-04 Zoltan Varga
>
>* processes.c: Applied more openbsd changes from Robert Nagy <
> rob...@openbsd.org>.
> @@ -128,7 +140,7 @@ Wed Feb 24 16:01:37 CET 2010 Paolo Molaro <
> lu...@ximian.com>
>
> 2009-09-01 Zoltan Varga
>
> - * processes.c (EnumProcessModules): Applied patch from Romain
> Tartière
> + * processes.c (EnumProcessModules): Applied patch from Romain
> Tartière
>(rom...@blogreen.org). Fix this on freebsd/OSX. Fixes #533893.
>
> 2009-08-18 Christian Hergert
> diff --git a/mono/io-layer/process-private.h
> b/mono/io-layer/process-private.h
> index a8b9f54..dc95283 100644
> --- a/mono/io-layer/process-private.h
> +++ b/mono/io-layer/process-private.h
> @@ -18,7 +18,11 @@
>
> /* This marks a system process that we don't have a handle on */
> /* FIXME: cope with pids > 16bit */
> +#if defined(__HAIKU__)
> +#define _WAPI_PROCESS_UNHANDLED_PID_MASK 0x7FFF
> +#else
> #define _WAPI_PROCESS_UNHANDLED_PID_MASK 0x7FFF
> +#endif
> #define _WAPI_PROCESS_UNHANDLED (-1 & ~_WAPI_PROCESS_UNHANDLED_PID_MASK)
>
> extern gpointer _wapi_process_duplicate (void);
> diff --git a/mono/io-layer/processes.c b/mono/io-layer/processes.c
> index 55d9600..98507d5 100644
> --- a/mono/io-layer/processes.c
> +++ b/mono/io-layer/processes.c
> @@ -54,6 +54,10 @@
> #endif
> #endif
>
> +#ifdef __HAIKU__
> +#include
> +#endif
> +
> #include
> #include
> #include
> @@ -1595,6 +1599,24 @@ gboolean EnumProcesses (guint32 *pids, guint32 len,
> guint32 *needed)
>
>return(TRUE);
> }
> +#elif defined(__HAIKU__)
> +
> +gboolean EnumProcesses (guint32 *pids, guint32 len, guint32 *needed)
> +{
> + guint32 fit, i = 0;
> + int32 cookie = 0;
> + team_info teamInfo;
> +
> + mono_once (&process_current_once, process_set_current);
> +
> + fit = len / sizeof (guint32);
> + while (get_next_team_info (&cookie, &teamInfo) == B_OK && i < fit)
> {
> + pids [i++] = teamInfo.team;
> + }
> + *needed = i * sizeof (guint32);
> +
> + return TRUE;
> +}
> #else
> gboolean EnumProcesses (guint32 *pids, guint32 len, guint32 *needed)
> {
> @@ -1681,6 +1703,9 @@ gpointer OpenProcess (guint32 req_access
> G_GNUC_UNUSED, gboolean inherit G_GNUC_
>if (handle == 0) {
> #if defined(__OpenBSD__)
>if ((kill(pid, 0) == 0) || (errno == EPERM)) {
> +#elif defined(__HAIKU__)
> + team_info teamInfo;
> + if (get_team_info ((team_id)pid, &teamInfo) == B_OK) {
> #else
>gchar *dir = g_strdup_printf ("/proc/%d", pid);
>if (!access (dir, F_OK)) {
> @@ -1958,6 +1983,37 @@ static GSList *load_modules (void)
>
>return(ret);
> }
> +#elif defined(__HAIKU__)
> +
> +static GSList *load_modules (void)
> +{
> + GSList *ret = NULL;
> + WapiProcModule *mod;
> + int32 cookie = 0;
> + image_info imageInfo;
> +
> + while (get_next_image_info (B_CURRENT_TEAM, &cookie, &imageInfo) ==
Re: [Mono-dev] [PATCH v2 6/7] eglib: Fix hardcoded library dependencies for Haiku
Looks ok.
Zoltan
On Mon, Apr 5, 2010 at 1:52 AM, Andreas Färber wrote:
> Haiku neither has libm nor libdl. On Mac OS X, libm.dylib is just a symlink
> to libSystem.dylib.
>
> Introduce autoconf checks for these libraries.
>
> v1 -> v2:
> * Add checks for libm and libdl.
>
> This commit is licensed under the MIT X11 license.
> ---
> eglib/ChangeLog|8
> eglib/configure.ac |2 ++
> eglib/src/Makefile.am |2 --
> eglib/test/Makefile.am |2 +-
> 4 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/eglib/ChangeLog b/eglib/ChangeLog
> index 5db80e9..d3ad576 100644
> --- a/eglib/ChangeLog
> +++ b/eglib/ChangeLog
> @@ -1,3 +1,11 @@
> +2010-03-30 Andreas Faerber
> +
> + * configure.ac: Add checks for libm and libdl.
> + * {src,test}/Makefile.am: Remove hardcoded library dependencies.
> + Fixes compilation on Haiku.
> +
> + Contributed under MIT/X11 license.
> +
> 2010-03-05 Zoltan Varga
>
>* test/test.c (_GNU_SOURCE): Fix compilation if _GNU_SOURCE is
> already defined.
> diff --git a/eglib/configure.ac b/eglib/configure.ac
> index f075d78..6d818ee 100644
> --- a/eglib/configure.ac
> +++ b/eglib/configure.ac
> @@ -70,6 +70,8 @@ AC_CHECK_SIZEOF(int)
> AC_CHECK_SIZEOF(void *)
> AC_CHECK_FUNCS(strndup strlcpy getpwent_r strtok_r rewinddir)
> AC_CHECK_LIB(iconv, libiconv_open, LIBS="$LIBS -liconv")
> +AC_SEARCH_LIBS(sqrtf, m)
> +AC_SEARCH_LIBS(dlopen, dl)
> old_ldflags="${LDFLAGS}"
> LDFLAGS="${LDFLAGS} -Wl,-export-dynamic"
> AC_TRY_LINK(, [int i;], found_export_dynamic=yes, found_export_dynamic=no)
> diff --git a/eglib/src/Makefile.am b/eglib/src/Makefile.am
> index 337c988..8cd29dc 100644
> --- a/eglib/src/Makefile.am
> +++ b/eglib/src/Makefile.am
> @@ -51,8 +51,6 @@ INCLUDES = -I$(srcdir)
>
> if HOST_WIN32
> libeglib_la_LIBADD = -lm -liconv -lpsapi
> -else
> -libeglib_la_LIBADD = -lm -ldl
> endif
>
> libeglib_static_la_LIBADD = $(libeglib_la_LIBADD)
> diff --git a/eglib/test/Makefile.am b/eglib/test/Makefile.am
> index 4f825b3..3411ef9 100644
> --- a/eglib/test/Makefile.am
> +++ b/eglib/test/Makefile.am
> @@ -30,7 +30,7 @@ SOURCES = \
> test_eglib_SOURCES = $(SOURCES)
>
> test_eglib_CFLAGS = -Wall -Werror -D_FORTIFY_SOURCE=2 -I$(srcdir)/../src
> -I../src -DDRIVER_NAME=\"EGlib\"
> -test_eglib_LDADD = ../src/libeglib.la -ldl
> +test_eglib_LDADD = ../src/libeglib.la
>
> run-eglib: all
>./test-eglib
> --
> 1.7.0.4.297.g6555b1
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
