Re: [Mono-list] Good Mono Project
VB6 was syntactically unsuited to .NET so came VB.NET, or so it was originally laid out. The reality is, if you are mired in VB6 syntax, go use RealBasic and target Windows, Linux Mac from the same IDE using the same syntax and compiler. VB6 syntax on top of the Mono .NET runtime just strikes me as round peg, square hole. It might fit, but it won't fill all the gaps. Andy On Mar 17, 2005, at 12:07 PM, Miguel de Icaza wrote: Hey, I'm not saying it can't be done -- it obviously can be. I'm just pointing out that this is A LOT of work; don't underestimate it. A Delphi-compatible compiler is trivial in comparison. VB6 language support is easy, the language semantics are easy, it's the class library support (and implicit Win32 support) which will be hard, especially since most of that class library consists of 3rd party components that may not have a Linux equivalent. The other downside is that it seems that VB6 is a different language that VBScript (used on web browsers) and different than VBA (Visual Basic for Applications). Someone who knows that stuff could probably say `this is a subset of that' or something along those lines and write a compiler that would work for all three. At least VBscript and VBA would be reusable elsewhere, and the VB6 support could help move *some* applications from Windows to Linux. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] RE: Support for .NET/COM interoperability
Erik is correct, you would absolutely want to use Remoting, not WS's for performance reasons. At my last job I tested this extensively as we had COM server objects in VB6 that we didn't have time or resources to port. The WebServices avenue was prettier and easier to deploy, but was significantly slower and more vulnerable to scalability issues. Andy On Jan 4, 2005, at 9:33 AM, Erik Dasque wrote: On Jan 4, 2005, at 7:16 AM, Jonathan Pryor wrote: There is an alternate approach, though: Leave your COM code on Windows, and write a .NET front-end which uses .NET COM Interop to use your COM objects. The front-end could be an XML Web Service or a System.Runtime.Remoting server, both of which Mono can communicate with. Thus you'd have: Mono/Linux -- [Network] -- .NET Web Service -- COM Component This is likely the easiest approach, though its performance won't be spectacular. - Jon Yes, I think that's the best option though you might want to use remoting instead of WS in that case. Erik ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Ask Microsoft: Mono support
I think that you are missing the most important words in your final assertion, I have rephrased it into what I think is the more realistic phrasing. Microsoft is happy that the Mono project gets more people to learn and use .Net. We can point to it if anybody complains that .Net isn't portable. But it ever poses a threat to us we reserve the right to ATTEMPT to pull the rug out from under it, and with the bumbling of our legal counsel, there is a good chance that all we would do is smear a bit of mud on our own faces, and all of this assumes that these actions don't place us in further danger of severe Justice Department and EU sanctions.. smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] About Mono License
If you contribute code to Mono, you know the license it is under, if you have the 'GPL only' virus ^H^H^H^H^H religion ^H^H^H^H^H^H^H^H^H disease ^H^H^H^H^H^H^H issue, then don't contribute your changes to the non GPL'ed portions of the code. Otherwise contribute in good faith in the interests of promoting the community. The core elements are dual licensed, but a commercial / proprietary license is frequently required by vendors that might like to build upon the Mono code and Novell would be foolish to not bend to that where it is applicable. Bear in mind these are the words of a developer that tries to contribute, not those of anyone on the Mono core team and I am in no way shape or form affiliated with Ximian or Novell, and this opinion is solely my own. Andy On Oct 19, 2004, at 3:50 PM, Manuel Alejandro Ceron Estrada wrote: Hi, I was reading the Mono FAQ and I found this: The Mono runtime and the Mono C# Compiler are also available under a proprietary license for those who can not use the LGPL and the GPL in their code. I have some questions about this: Mono been made by many voluntary developers in addition to those of Novell. Are those voluntary developers agree with a proprietary license? What if some contributor wants to help in the Mono project, but does not want to see his code under a proprietary license? There is conflict between the GPL and the propietary license? Of course, I'm talking about the Mono parts under GPL and LGPL (the C# Compiler and the Runtime Library), not about the parts under MIT-X11 license Thanks, Manuel Alejandro Cerón Estrada. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] SqlConnection in Mac OS X
Only in HEAD. Andy - [EMAIL PROTECTED] - druware software designs http://www.druware.com On Aug 27, 2004, at 12:28 PM, Jonel Rienton wrote: Hi guys, has the patched been applied in the cvs? thanks... regards, jonel On Tue, 24 Aug 2004 18:39:01 -0400, Daniel Morgan [EMAIL PROTECTED] wrote: If your patch to SqlClient works on Mac OS X, and it does not break anything on Windows nor Linux. Then please go ahead and commit it. Unless, Tim has any objections. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Satori Sent: Tuesday, August 24, 2004 3:05 PM To: Jonel Rienton Cc: [EMAIL PROTECTED] Subject: Re: [Mono-list] SqlConnection in Mac OS X There is, as well as a proposed patch to Mono.Tds (which underlies this). There is a ByteOrder problem with the SqlConnection. Andy bugzilla bugid= 62948 - [EMAIL PROTECTED] - druware software designs http://www.druware.com On Aug 24, 2004, at 2:50 PM, Jonel Rienton wrote: hi guys, I was doing some testing in the System.Data namespace in my mac and I got stuck to something. whenever i call the Open method of a SqlConnection object, the cpu goes up high and the application just sits there with no messages. the same code compiled in my linux box works beautifully (thanks!) mac box: Mac OS X Panther in a PowerBook linux box: RedHat 9 in an AMD 350 box Is there any bug open about this? regards, --j ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SqlConnection in Mac OS X
There is, as well as a proposed patch to Mono.Tds (which underlies this). There is a ByteOrder problem with the SqlConnection. Andy bugzilla bugid= 62948 - [EMAIL PROTECTED] - druware software designs http://www.druware.com On Aug 24, 2004, at 2:50 PM, Jonel Rienton wrote: hi guys, I was doing some testing in the System.Data namespace in my mac and I got stuck to something. whenever i call the Open method of a SqlConnection object, the cpu goes up high and the application just sits there with no messages. the same code compiled in my linux box works beautifully (thanks!) mac box: Mac OS X Panther in a PowerBook linux box: RedHat 9 in an AMD 350 box Is there any bug open about this? regards, --j ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Yes again sorry - XSP / mod_mono on Mac OS X
smime.p7m Description: S/MIME encrypted message
Re: [Mono-list] XSP on OS X ?
XSP is currently very broken on OSX. The AppDomain bug.. Andy On Jul 8, 2004, at 6:10 AM, manu wrote: On Mon, 2004-07-05 at 20:32, manu wrote: Does anybody have this problem with OS X ? I get a U_FILE_ACCESS_ERROR with xsp and mod_mono ? Whoever built your ICU needs to rebuild it without configuring --with-data-packaging=files. See http://bugzilla.ximian.com/show_bug.cgi?id=52065 Thanks, on os x I builded icu 3.0 from IBM, but I still get the same message. I have to use the icu ximian package I think, but there is a lot of dependencies to resolve. Is there maybe a tar.gz version out there ? Or better, an OS X one ? Manu ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] XSP on OS/X -- assertion failed
XSP is currently broken on OS X due to an issue in the JIT. Andy On Jul 8, 2004, at 7:32 AM, Bryan Zarnett wrote: After compiling and attempting to run XSP on OS/X I get the following error when I try to hit the server: ** ERROR **: file exception-ppc.c: line 930 (ves_icall_get_trace): asertion failed: (ji !=NULL) When I run XSP (mono xsp.exe) The application prints out the following basic details: Adding applications '/:.'... Registered application: Host: any Port: any Virtual Path: / Physical Path: /usr/local/xsp/bin Listening on Port: 8080 Listening on address: 0.0.0.0 Root Directory: /usr/local/xsp/bin Any help in solving this impediment would be great. Bryan ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] [ann] Mono Starter for OS X
Only if X is already running and you have your default Terminal environment setup to launch X apps from Terminal. Andy On 6/18/04 1:00 PM, Elfred Pagan [EMAIL PROTECTED] pounded the keyboard to produce: Does it work with GTK# Applications? On Fri, 18 Jun 2004 18:20:53 +0200, l0ne [EMAIL PROTECTED] wrote: Hi everyone! I was quite intrigued by the chance of having .NET applications also run on my beloved iMac, but I'm quite terminalphobic -- so, after having seen that .NET exes work on my Mac (yeah!), I've written a small starter .app to run exes by double-clicking. THINGS IT DOES: - It works with both mono and ilrun (portable.net). - Starts applications in Mac OS X's Terminal.app. - Registers .exes and .dlls with cute, shiny, handmade, emblazoned-with-mono-logo custom icons, removing that ugly Virtual PC icon from them (which is Windows's default icon for exes, just stretched to 128x128. Not redrawn to look good in 128x128. Just 32x32 icons stretched to that size. Ugh). - Detects mono and ilrun by watching into common directories (/usr/bin, /usr/local/bin, /opt/local/bin, /Library/Frameworks/Mono.framework and so on). - If a .NET environment is not detected, it offers the user a chance to install Mono or Portable.NET from a PKG (if such a package is put into the program's Resources folder) or, if none is available, shows links to go-mono.org and dotgnu.org. Which means that the program allows for dumb-proof drag'n'drop installation of Mono (by taking extra steps on first launch as per Apple Human Interface Guidelines). - Can be configured to launch X11 along with the Terminal, allowing programs that use Windows.Forms or other windowing toolkits to start correctly. THINGS IT DOESN'T DO: - The preferences aren't complete yet - they don't disable the Use Mono or Use DotGNU option even when the corresponding piece of software isn't available, very possibly leading to bad behavior (NullPointerExceptions suddenly finding their way into the Console at the very least). - It doesn't allow the user to turn off the Terminal -- that is, to load the .exe without having the Terminal window show up. Mainly because I'm lazy. - It doesn't make any coffee. - It has no way of intelligently understanding whether a program is console-only or uses a windowing toolkit, so you must activate or deactivate X11 manually for now. - It does not pass any command-line parameters to the .exe being started. Again that's because I'm just lazy. You can find the .app (with no .pkg inside its Resource folder) at http://matrixtcg.altervista.org/monostarter.zip and source at http://matrixtcg.altervista.org/monostarter.src.zip (pay attention: the .xcode project refers to a portable.net.pkg that isn't there for size reasons. Just remove it, the program will detect the absence of pkgs in the Resources folder and work just fine). I haven't included a license in the .zip but I will soon, and it will be GPL. - e. v. aka l0ne -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Lerboristeria.biz: per la tua bellezza e salute il miglior assortimento * di prodotti erboristici ed oggettistica online * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2152d=18-6i?mid=2380d=18-6 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] ADODB.dll
Not on a non-windows platform. ADODB.dll is a wrapper around the underlying MSADO COM interfaces and there is not support to use those on non-windows platforms as far as I know. Andy On 6/8/04 9:37 AM, KiOrKY [EMAIL PROTECTED] pounded the keyboard to produce: hi, *is this possible to use ADODB.dll from miocrosft and how? because when i execute program even if i copy the dll in a dir and register $MONO_PATH i have : ** (../magellan/magellan/Designer v2/Designer/bin/Designer.exe:8817): WARNING **: Could not find assembly FarPoint.Win.Spread, references from /home/kiorky/dll/ToolBoxWinSpread.dll (assemblyref_index=8) Major/Minor: 1,0 Build: 4,0 Token: 327c3516b1b18457 regards ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Is it Mono safe?
After reading through the blog post, it sounds more like Red Hat posturing than a real problem as well. Red Hat and Novell are entering a seriously competitive stage in their businesses, and view each other as strong competitors. There is a need right now to minimize the impact of Mono by RedHat, as their refusal to ship with Mono has the potential to handicap them. All of that said, the legal issue is only an issue if it is allowed to become one. There is no question that there are some assemblies that could be legally entangled, that no different than C or C++ libraries that have been discovered to have infringing code in the past. They will be replaced with non-infringing code before the press release is cold, by the community. Even with that threat, I maintain that Microsoft is too shrewd a marketing company to hand Justice and their very able competitors, Apple, Novell, and Red Hat a smoking gun like that. They have commited to the .NET / C# path, and with Rotor, they opened a floodgate that they cannot close without raising serious issues across the board. When you look at the license around Rotor, you'll notice that it was to encourage non-Microsoft developed CLI / CLR implementations and to encrouage educational adoption of the technology and platform as a teaching technology. It is a prime example of embrace and extend. The only way that MS maintains it's clear lead in the managed code world is to innovate and release new technologies faster than the OSS community can. So far they have a 2 year lead, and there is no question that they are aware of Mono (and Portable.NET). The long and short of it is that, in business, you have to gamble on occasion. If you choose to gamble the C or C++ is going to remain the foundation language of development, then you can keep doing what you are doing. You could also gamble that Sun is going to stay solvent and keep Java relevant. You could gamble that C# and the .NET platform are here for the next 10-15 years (something will replace it, something always does), and embrace Mono, after all, what's the worst case scenario, you have redeploy to Windows machines for a short transition period? Most Linux Mono machines are x86 hardware, so at worst you are faced with Windows licensing costs. Most of your hardware came with a Windows license anyways. Microsoft is anything but dumb, they will be just as happy to leverage global domination through development tools and technology as they have ben to use extortion, bundling and strongarm tactics. Office did not get to it's dominance by being the worst product. They did innovate, and create a better overall product when they had viable competition. Only when they've killed off competition have they become stagnant. Andy On May 20, 2004, at 9:04 AM, Melinda wrote: Thankx for the reply. I appreciate it. On Thu, 2004-05-20 at 17:53, [EMAIL PROTECTED] wrote: Some information... http://www.oreillynet.com/pub/wlg/4557 Miguel and Novell legal staff are currently conducting a formal patent review of mono, and the team had already split up the components of mono into separate ECMA-based and non-ECMA components (WinForms, ADO.NET, etc) to clearly define what RedHat and others could make use of. Importantly, Miguel also said that Ximian had a letter from Microsoft, Intel and HP stating that they would offer *royalty-free* RAND licensing to the ECMA-submitted components of .NET. [Aside: He said they were kicking around catchy names like 'polio' or 'cholera' to distinguish the free and non-free stacks] I told Miguel he should publicize the letter more because it was such a relief to me, but he said it would be premature to promote this before the patent review was complete in case other infringement was uncovered. http://www.go-mono.com/faq.html#patents Most importantly: For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration. http://www.mail-archive.com/[EMAIL PROTECTED]/msg06501.html Read Andy Satori's very well though out response, also Miguel's second response further down in the thread. I believe Andy hit the nail on the head with regards to the possibility of MS imposing restrictions on Mono in the future. MS are trying to better their image. They are now even releaseing old source on sourceforge. They would not benefit from any future attack on Mono. http://nwc.linuxpipeline.com/showArticle.jhtml?articleID=20300445 Yet according to de Icaza, open source advocates have blown the royalty issue out of proportion. We already know that the ECMA components are royalty-free, he stated. To the best of my knowledge, I am not aware of any libraries or other parts that would have to be licensed under royalty terms from Microsoft. I think this issue comes up more because people in the open source community are scared of Microsoft and because they're ill-informed about the
Re: [Mono-list] About RPMS of .NET packages (using MonoDevelop as a case study)
I think it make perfect sense, but since it would make it easier for 'users' and not require a techie that has not reached a significant knowledge level with AutoTools I think the bulk of the Unix world will think it's a very very bad idea. Andy On Apr 2, 2004, at 9:44 AM, Philippe Lavoie wrote: Hi folks, There was a small discussion which stemed from the release of MonoDevelop. MonoDevelop already has a list of RPMS which are needed for it to work. However, I think that having multiple RPMS is braking the .NET spirit. Let me explain. Then flame away. In .NET, they try hard to break the DLL hell. There are two solutions, the GAC and copying everything locally. The GAC is work in progress with mono, so lets focus on the other one. According to the .NET philosophy, every managed dependency of MonoDevelop should be bundled inside its own package and thats it. The only dependencies should be the unmanaged ones. Maybe have a .NET application binary package could/should/would unbundle to a structure as follows Application.exe Application # this would be a sh script which calls the exe Application.exe.libs/ Application.exe.libs/lib1.dll Application.exe.libs/lib2.dll Application.exe.libs/lib3.dll Application.exe.config One of the things I notice with unix is that I need to do a lot of dependency checking before I get something up and running. The above structure would remove this (except for unmanaged dependencies) and it could be optimize when someone compiles by source since the libraries might already be inside the GAC. The philosophy I think is that hard disk is cheap and DLL hell is not cheap. Anyway, I liked it when I installed Axiom. It also contained the Tao and other managed libraries it needed. I didnt need to fetch 3 or 4 more packages. In Linux, we also have dependency hell with RPMS when you start to mix compiling from source and adding RPMS made by different vendors, etc. We should move away from that model, gtk#.dll could have been bundled with MonoDevelop. If people want to put all dependencies in a GAC or something, they will need a real installer. Otherwise its the copy everything locally methodology. At least according to the philosophy of .NET. Do we have an installer for mono applications under Unix yet? What do you guys think? Philippe Lavoie Cactus Commerce eBusiness. All Business. Tel 819.778.0313 x302 888.CACTUS.0 Fax 819.771.0921 www.cactuscommerce.com [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and Patents....
rant Please excuse me for my bluntness. The Microsoft Patent in this instance is largely irrelevant, for the very reasons that you mention as being reasons to worry. Nothing, and I mean nothing, that Microsoft could do technically would be as critically damaging to the already fragile, and crumbling image that Microsoft has within the Enterprise world, than attempting to leverage that patent upon the standards body that they are working with. Further, that very excercise would undermine their efforts with the Media codecs and the standards bodies. It would be tantamount to aiming a gun at your foot, pulling the trigger and wondering how you got shot in the foot. Further, for Microsoft, Mono is a 'good thing' because while it means that .NET code is easier to port to non-Windows platforms, it also means that their chosen language will be the language of choice on many platforms, expanding their reach as well as the reach of their tools. After all, Windows itself is a means to an end, not the end itself. It's all about profit. So long as Windows generates revenue, it's a winner. Today, Windows generates a profit because it leverages Office into the enterprise world, where profits are the most easily recognized. The .NET framework is another road to leveraging that profit center. By getting developer's regardless of platform, to leverage a technology that helps them sell units of Application Center ($30k / CPU), BizTalk ($28k / CPU), SQL Server ($12k) etc. These are pure, unadulterated profits, and they leverage Windows and .NET, but they have no value if the marketplace cannot consume them. Mono not only makes consumption feasable, but practical. Further Mono's licensing, much like that of Rotor is such that the code you generate using these open source tools is completely yours to place under any license you wish, so long as you aren't shipping modified versions of GPL'd code. The same as code generated by Microsoft's compilers doesn't restrict your rights on the generated output. All of that said, and bear in mind, that until fairly recently I was for all intents and purposes and Microserf. I used Windows 286, then Windows 386, and Windows 3. I followed the Microsoft line and went to Microsoft OS/2, then followed back to Windows NT 3.1, and 3.51, NT4, 2000, XP. I played with Linux, BeOS and a few others along the way, but along the way, I followed the MS development line. I've practiced what they preached. Today, I'm still doing so, only I'm doing it using Mono, on my Mac. Why? because I can. And that my friend, is the point. Mono, gives the consumer the one thing that Microsoft needs the most, and the one thing that will keep them away from stiff, possibly corporate entity threatening sanctions for their behaviour. Mono, is the Apple in the development tools ointment that Microsoft requires to keep themselves solvent, and there is no better motivation for a company predicated on profit than staying solvent, and retaining the freedom to compete. That bevy of smarmy bastards known as the Microsoft Legal team are more aware of the fine line between competition and a monopoly than any of us, they watched the damage that the consent decree did to IBM 30 years ago, they are unlikely to allow themselves to be put in the same position. /rant Sorry but I had to get that off my chest. Andy ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Ok, after alot more digging and experimenting, there is a ton of work to make this like the Java implementation, which, I still think is the 'correct' answer, but it's going to have to be the longer term answer. I don't think we can get it all done between now and the next release without more time and resource than I can dedicate to it. Here is what I would propose: Phase I: A .pkg installer that installs Mono and Mcs to /usr/local/, with a detailed description on how to properly set up the environment to use /usr/local/bin. This package would use glib statically linked, to avoid the need to also deploy glib to the users machine. Seperate .pkg installers would also be made available for XSP, MOD_MONO, GTK# and any other optional elements of Mono. Phase II: A process to automatically build the Mono and Mcs into a standalone MonoVM.Framework that installs to /Library/ with an installer (.pkg) that aliases the core commands, mono, mint, mcs, and the others to /usr/bin. I know that Apple reserves the right to the /usr/bin directory, but from an Apple 'it just works' perspective, it is the only place to put them. With Phase II, it would be feasable to ship .app bundles that uses an exectuable that calls the /usr/bin/mono framework and launches just like any other OS X application. Ultimately, this opens the door for Mono to provide the same level of application parity as Java, Cocoa (Objective C), or Carbon (C/C++). The problem with the second is that as far as I can tell, it would require XCode projects to build the framework, and all the associated dylibs. creating that project is going to be time consuming, and it will require updating to be kept in sync with the ./configure make process. I've got most of Phase I complete at this point, I'm doing some testing now, and should have a working deliverable in the next few days. Once that is completed, I'll begin the long and arduous process of doing Phase II. Andy Satori On Feb 25, 2004, at 9:22 AM, Urs Muff wrote: This is great! Please publish the Xcode projects and scripts you use to make the package and framework so others can build it from CVS. Miguel or myself will check them into CVS in case you don't have access. - Urs -Original Message- From: Andy Satori [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 7:21 AM To: Urs Muff Cc: 'Miguel de Icaza'; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Urs is correct, after some more digging, it's the 'way' to go. it's going to take me a couple of days to cleanup my own system to get all this built and tested (wish I had another machine for this... oh well). I've got the packages and base installer's built, I just need to run through and tweak them into frameworks. This will also make them much easier to install and manage in the future. Andy On Feb 25, 2004, at 8:21 AM, Urs Muff wrote: If you actually look at /usr/bin/javac, /usr/bin/java, those are soft links to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java. -- We only have to create soft links for stuff main executables, but not necessary the .exe assemblies since those are just .Net assemblies unless we have some .exe Mono launcher in /etc/... as discussed many times on this list. As for the version: that is the framework version not the assembly version. The GAC is fine and no problem, but Apple is talking about the executables (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and that has a standard folder structure. - URS C. MUFF -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 7:43 PM To: Urs C Muff Cc: Andy Satori; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Hello, Well actually I agree that the shell scripts 'mono' and 'mcs' might live in /usr/bin, but I would create a Framework and put it in /System/Library/Frameworks/MonoVM.Framework the same way as /System/Library/Frameworks/JavaVM.Framework is placed (look at the folder structure within the framework to see how Apple is structuring such a beast). But the .Net assemblies should live in /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. That would conform with Apple's standard much better: I don't know how we would have to build mono to include those in the assembly load path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] MacOS packages.
I agree, /Library has to be it's ultimate home, but right now, OS X is a disaster regarding anything else. Fink uses /sw/ (huh?) darwinports uses /opt/ and /opt/local/ (huh? further). I want to get everything into the Framework under /Library, but the default build process right now makes that a time consuming task. If you are talking 2-3 weeks until the next release, I'll never get it done in time. If it's 2 months, I might pull it off :-). I simply don't have the copious spare time to to it, and my day job frowns upon Open Source, so I have to work at it in my off hours :-). That said, I;m going in the direction, and Benjamin had a couple of pointers that should help quite a bit, but it's still going to take time. Please bear in mind, that while I have a reasonable Unix comfort level, I'm by no means an expert, every flavor I've ever used treats /usr/local and /opt differently. Exacerbating that issue is that I've spent the last 10 years doing Windows development. So I'm very flexible regarding this, and the /usr/local was mostly done because that seems to be where most of the .pkg's I've installed put things. I'll adjust accordingly. Andy On Mar 2, 2004, at 7:20 PM, Miguel de Icaza wrote: Hello, Phase I: A .pkg installer that installs Mono and Mcs to /usr/local/, with a detailed description on how to properly set up the environment to use /usr/local/bin. This package would use glib statically linked, to avoid the need to also deploy glib to the users machine. I also agree with the other poster that /usr/local should be reserved for the local system administrator. As I said previously, I think we should stick stuff in /Library, and install links in /usr/bin for the programs. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] MacOS packages.
Urs is correct, after some more digging, it's the 'way' to go. it's going to take me a couple of days to cleanup my own system to get all this built and tested (wish I had another machine for this... oh well). I've got the packages and base installer's built, I just need to run through and tweak them into frameworks. This will also make them much easier to install and manage in the future. Andy On Feb 25, 2004, at 8:21 AM, Urs Muff wrote: If you actually look at /usr/bin/javac, /usr/bin/java, those are soft links to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java. -- We only have to create soft links for stuff main executables, but not necessary the .exe assemblies since those are just .Net assemblies unless we have some .exe Mono launcher in /etc/... as discussed many times on this list. As for the version: that is the framework version not the assembly version. The GAC is fine and no problem, but Apple is talking about the executables (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and that has a standard folder structure. - URS C. MUFF -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 7:43 PM To: Urs C Muff Cc: Andy Satori; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Hello, Well actually I agree that the shell scripts 'mono' and 'mcs' might live in /usr/bin, but I would create a Framework and put it in /System/Library/Frameworks/MonoVM.Framework the same way as /System/Library/Frameworks/JavaVM.Framework is placed (look at the folder structure within the framework to see how Apple is structuring such a beast). But the .Net assemblies should live in /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. That would conform with Apple's standard much better: I don't know how we would have to build mono to include those in the assembly load path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate packages. On the ICU (and GC) front, I currently build without either, but once I get all the foundation in place, I'll add them. With XCode, I currently have a C# language filter defined so that XCode can parse the functions and color C# files. I also have a Makefile based project template for building a C# application in XCode. I'm now working on enhancing that to be a part of the XCode native build system, instead of the old Project Builder, jam based, build system. This will improve the error parsing and display, as well as allow you to use the much more powerful Info panels in XCode to set up your build environments. After that, it is my intent to build a library of templates for XCode to setup your basic projects, much like VS.NET. Hopefully by that time, Apple will have updated XCode to make it easier to integrate external debuggers into XCode, and I'll be able to add that. Andy On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote: What about GTK# ? Is that Mono built with ICU, Andy ? What are you doing with XCode ? Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
At the moment, my primary installation is a CVS build. I did all the dependancy work and checks on a clean OS X install (gotta love firewire external drives) and it's using 0.30.2, as it's a quicker and easier build process on a virgin machine. Once I have the basics established, I'll bring it all up to date, including updating to the newly releasesd GLib 2.3.3. Andy On Feb 25, 2004, at 11:37 AM, Erik Dasque wrote: Andy, The xcode stuff sounds great. Are you packaging 0.30.2 or a cvs build ? I don't believe the ppc fix is in the releases yet. I have found that many applications crash (Bus error) without it thus far (including a lot of GTK# apps). Do you use the interpreter only ? Also, I believe ICU is needed to run monodevelop, wink, wink. Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
OK, following up my own post and thoughts. I went ahead and installed OS X 10.3 on an external FW drive, and just built a ground up Mono install using pkg-config 0.15.0, glib-2.3.1, gettext 0.11.5, and mono-0.30.1. And I'm getting ready to assemble the .pkg files for those installations. The question now becomes, where to put them... On a fresh installation of OS X, /usr/local/bin is not in the path. Everything lives in /usr/bin, including java, javac, php, ruby, and python. Based upon that, we have the option of installing Mono and it's dep's into /usr/ /usr/local/ or /opt/. For the average user, installing it to /usr/ means that it will just magically work. The other alternative is to write a shell script to alter the systemwide environment variables, but this would be overwritten by every .x.x patch to the OS. With the change to bash, we could alter it for the terminal windows, but spawned tasks would not have the correct environment by default. Looking at the way that Apple integrated Java into the operating system, it looks like the proper way to do this would be to go to /usr/ as this would allow Mono development to build applications that are deployed in name.app bundles just like Java applications and be executable in the same fashion, giving Mono apps the same level of system parity as Java. The only negative I see with this is that it might conflict with other versions of glib-2 or gettext on the system. It might give some strange interactions with DarwinPorts or Fink applications. Does anyone have any thoughts? Andy Satori On Feb 24, 2004, at 2:37 PM, Andy Satori wrote: This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Yes, you are correct, though I suspect that's going to require some manual rebuilding of Mono itself. Andy On Feb 24, 2004, at 7:34 PM, Urs C Muff wrote: Well actually I agree that the shell scripts 'mono' and 'mcs' might live in /usr/bin, but I would create a Framework and put it in /System/Library/Frameworks/MonoVM.Framework the same way as /System/Library/Frameworks/JavaVM.Framework is placed (look at the folder structure within the framework to see how Apple is structuring such a beast). But the .Net assemblies should live in /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. That would conform with Apple's standard much better: I don't know how we would have to build mono to include those in the assembly load path... - Urs On Feb 24, 2004, at 5:11 PM, Andy Satori wrote: OK, following up my own post and thoughts. I went ahead and installed OS X 10.3 on an external FW drive, and just built a ground up Mono install using pkg-config 0.15.0, glib-2.3.1, gettext 0.11.5, and mono-0.30.1. And I'm getting ready to assemble the .pkg files for those installations. The question now becomes, where to put them... On a fresh installation of OS X, /usr/local/bin is not in the path. Everything lives in /usr/bin, including java, javac, php, ruby, and python. Based upon that, we have the option of installing Mono and it's dep's into /usr/ /usr/local/ or /opt/. For the average user, installing it to /usr/ means that it will just magically work. The other alternative is to write a shell script to alter the systemwide environment variables, but this would be overwritten by every .x.x patch to the OS. With the change to bash, we could alter it for the terminal windows, but spawned tasks would not have the correct environment by default. Looking at the way that Apple integrated Java into the operating system, it looks like the proper way to do this would be to go to /usr/ as this would allow Mono development to build applications that are deployed in name.app bundles just like Java applications and be executable in the same fashion, giving Mono apps the same level of system parity as Java. The only negative I see with this is that it might conflict with other versions of glib-2 or gettext on the system. It might give some strange interactions with DarwinPorts or Fink applications. Does anyone have any thoughts? Andy Satori On Feb 24, 2004, at 2:37 PM, Andy Satori wrote: This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Building from CVS doesn't work
hmm, this is the same error I was seeing on OS X... On Jan 30, 2004, at 11:05 AM, Sebastien Pouliot wrote: For this error to appear you (strangely) do not seems to define either NET_1_1 or NET_1_0 (HMAC class being only present in 1.2). Are you sure all your makefiles are in synch with CVS ? Sebastien Pouliot home: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/poupou.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pieter Laeremans Sent: 30 janvier 2004 10:57 To: [EMAIL PROTECTED] Subject: [Mono-list] Building from CVS doesn't work I've get an error every time I'm trying to build mono from cvs. First I've installed mono 0.28 on my system. Which worked. I can compile a simple .cs file. Then I 've got mono and mcs from cvs but when I try a fullbuild I get the following result : [EMAIL PROTECTED]:~/mono/mono$ make fullbuild rm ../mcs/class/lib/mscorlib.dll ../mcs/mcs/mcs.exe runtime/*dll runtime/*.exe /dev/null 21; echo (cd ../mcs/jay; make) make[1]: Entering directory `/home/pieter/mono/mcs/jay' make[1]: Leaving directory `/home/pieter/mono/mcs/jay' (cd ../mcs/mcs; make MCS=mcs BOOTSTRAP_MCS=mcs) make[1]: Entering directory `/home/pieter/mono/mcs/mcs' mcs /lib:/usr/local/lib -g /target:exe /out:mcs.exe AssemblyInfo.cs anonymous.cs assign.cs attribute.cs driver.cs cs-tokenizer.cs cfold.cs class.cs codegen.cs const.cs constant.cs convert.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs flowanalysis.cs genericparser.cs interface.cs iterators.cs literal.cs location.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs rootcontext.cs statement.cs support.cs typemanager.cs symbolwriter.cs tree.cs cs-parser.cs Compilation succeeded make[1]: Leaving directory `/home/pieter/mono/mcs/mcs' (cd ../mcs/class/corlib; make MCS=mcs BOOTSTRAP_MCS=mcs) make[1]: Entering directory `/home/pieter/mono/mcs/class/corlib' mcs /nowarn:649 /nowarn:169 -d:INSIDE_CORLIB /lib:/usr/local/lib -g /noconfig /unsafe /nostdlib /target:library /out:../../class/lib/mscorlib.dll @../../build/deps/corlib.dll.response System.Security.Cryptography/HMACSHA1.cs(110) error CS0246: Cannot find type `HMAC' Compilation failed: 1 error(s), 0 warnings make[1]: *** [../../class/lib/mscorlib.dll] Error 1 make[1]: Leaving directory `/home/pieter/mono/mcs/class/corlib' make: *** [mcs-tree-safe-build] Error 2 What am I doing wrong ? thanks in advance, Pieter ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [patch] MacOSX autoconf/automake fixes
It's really sad, I know this, but I think the Benadryl (cold medicine) effect caught up with me. It's rebuilding now, I should have more on the actual test suite later. Thanks, Andy On Jan 28, 2004, at 6:24 AM, Paolo Molaro wrote: ACLOCAL_FLAGS=-I /opt/local/share/aclocal/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] [patch] MacOSX autoconf/automake fixes
With the current AnonCVS snapshot on 10.3.2 autogen.sh still fails out of the gate, and must be worked around: checking for pkg-config... /opt/local/bin/pkg-config ./configure: line 20045: syntax error near unexpected token `BASE_DEPENDENCIES,' ./configure: line 20045: `PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION)' where: 'which pkg-config' returns: '/opt/local/bin/pkg-config' where: 'pkg-config --cflags glib-2.0' returns: '-I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include' modifying ./configure.in to skip this check results in a complete run make fullbuild fails: make[3]: Nothing to be done for `install-data-am'. (cd runtime; make install assemblies_DATA=mscorlib.dll monobins_DATA=mcs.exe) make[2]: Nothing to be done for `install-exec-am'. /bin/sh ../mkinstalldirs /usr/local/lib /usr/bin/install -c -m 644 mscorlib.dll /usr/local/lib/mscorlib.dll /bin/sh ../mkinstalldirs /usr/local/bin /usr/bin/install -c -m 644 mcs.exe /usr/local/bin/mcs.exe (cd ../mcs/class; make) Creating ../../../build/deps/I18N.dll.makefrag ... touch ../../../build/deps/I18N.dll.stamp MONO_PATH=../../../class/lib:$MONO_PATH mono ../../../mcs/mcs.exe /r:mscorlib.dll -d:NET_1_1 -d:ONLY_1_1 -g /noconfig /target:library /out:../../../class/lib/I18N.dll @I18N.dll.sources Unhandled Exception: System.IO.FileNotFoundException: File 'mscorlib.dll' not found. in (unmanaged) (wrapper managed-to-native) System.Reflection.Assembly:LoadFrom (string) make[3]: *** [../../../class/lib/I18N.dll] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [mcs-rest] Error 2 looks like there is a missing /lib:../../../class/lib still alot of warnings about point from int without cast, added to my todo list of things to cleanup if / when I get time (tramp-ppc.c) Andy On Jan 27, 2004, at 11:07 AM, Andy Satori wrote: I'm pulling a current CVS right now, and I'll run the test this evening. Andy On Jan 27, 2004, at 10:54 AM, Paolo Molaro wrote: On 01/26/04 Benjamin Reed wrote: Attached is a patch that fixes these issues properly, within autoconf and automake. You still need to do glibtoolize and friends (autogen.sh stuff) until a new release is made, though. Thanks for the patch: the issues should be already fixed in cvs without any additional patch. Feel free to try and report if it works for you. Also reports of running the jit on 10.3 (success or failure for make test in mono/mono/tests) are appreciated. Thanks. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] DESTDIR problem (on OS-X)
Is there any particular reason you are using 0.26 over 0.28? and are you working with 10.2.x or 10.3.x? While I did finally get a successful build, but not a working installation on 10.2.8, I've not had any luck getting 0.28 built on OS X 10.3.1. I've slowly working through the build errors. Andy On Nov 21, 2003, at 10:24 AM, Markus W. Weissmann wrote: Hi folks, I'm trying to build and install Mono 0.26 on OS-X: when making a 'make install DESTDIR=..., I'll get an error, as it seems it likes to do some late linking and assumes the files to be in the final destination (/opt/local in this case), not in DESTDIR. Can someone help me solve this one? I assume this is a OS-X specific bug; thanks, mww --- /bin/sh ../../mkinstalldirs /Users/mww/Development/dports/devel/mono/work/destroot/opt/local/lib /bin/sh ../../libtool --mode=install /usr/bin/install -c libmono-profiler-cov.la /Users/mww/Development/dports/devel/mono/work/destroot/opt/local/lib/ libmono-profiler-cov.la libtool: install: warning: relinking `libmono-profiler-cov.la' (cd /Users/mww/Development/dports/devel/mono/work/mono-0.26/mono/profiler; /bin/sh ../../libtool --mode=relink gcc -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -L/opt/local/lib -pthread -o libmono-profiler-cov.la -rpath /opt/local/lib mono-cov.lo ../../mono/mini/libmono.la -lpthread -inst-prefix-dir /Users/mww/Development/dports/devel/mono/work/destroot) gcc -r -keep_private_externs -nostdlib -o .libs/libmono-profiler-cov.0.0.0.dylib-master.o mono-cov.lo gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libmono-profiler-cov.0.0.0.dylib .libs/libmono-profiler-cov.0.0.0.dylib-master.o -L/opt/local/lib /opt/local/lib/libmono.dylib -lpthread -lc -install_name /opt/local/lib/libmono-profiler-cov.0.dylib -compatibility_version 1 -current_version 1.0 gcc: /opt/local/lib/libmono.dylib: No such file or directory libtool: install: error: relink `libmono-profiler-cov.la' with the above command before installing it make[3]: *** [install-libLTLIBRARIES] Error 1 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 --- Markus W. Weissmann http://www.mweissmann.de/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] DESTDIR problem (on OS-X)
As an aside, I'm down to just a couple of errors of relevance: Warnings: ld: warning multiple definitions of symbol _locale_charset /usr/lib/libiconv.dylib(localcharset.o) definition of _locale_charset /usr/local/lib/libintl.dylib(localcharset.o) definition of _locale_charset ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used symbol _locale_charset used from dynamic library /usr/lib/libiconv.dylib(localcharset.o) not from earlier dynamic library /usr/local/lib/libintl.2.dylib(localcharset.o) Errors: ld: Undefined symbols: _mono_unicode_from_external _mono_unicode_to_external _mono_utf8_from_external On Nov 21, 2003, at 10:24 AM, Markus W. Weissmann wrote: Hi folks, I'm trying to build and install Mono 0.26 on OS-X: when making a 'make install DESTDIR=..., I'll get an error, as it seems it likes to do some late linking and assumes the files to be in the final destination (/opt/local in this case), not in DESTDIR. Can someone help me solve this one? I assume this is a OS-X specific bug; thanks, mww --- /bin/sh ../../mkinstalldirs /Users/mww/Development/dports/devel/mono/work/destroot/opt/local/lib /bin/sh ../../libtool --mode=install /usr/bin/install -c libmono-profiler-cov.la /Users/mww/Development/dports/devel/mono/work/destroot/opt/local/lib/ libmono-profiler-cov.la libtool: install: warning: relinking `libmono-profiler-cov.la' (cd /Users/mww/Development/dports/devel/mono/work/mono-0.26/mono/profiler; /bin/sh ../../libtool --mode=relink gcc -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -L/opt/local/lib -pthread -o libmono-profiler-cov.la -rpath /opt/local/lib mono-cov.lo ../../mono/mini/libmono.la -lpthread -inst-prefix-dir /Users/mww/Development/dports/devel/mono/work/destroot) gcc -r -keep_private_externs -nostdlib -o .libs/libmono-profiler-cov.0.0.0.dylib-master.o mono-cov.lo gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libmono-profiler-cov.0.0.0.dylib .libs/libmono-profiler-cov.0.0.0.dylib-master.o -L/opt/local/lib /opt/local/lib/libmono.dylib -lpthread -lc -install_name /opt/local/lib/libmono-profiler-cov.0.dylib -compatibility_version 1 -current_version 1.0 gcc: /opt/local/lib/libmono.dylib: No such file or directory libtool: install: error: relink `libmono-profiler-cov.la' with the above command before installing it make[3]: *** [install-libLTLIBRARIES] Error 1 make[2]: *** [install-am] Error 2 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 --- Markus W. Weissmann http://www.mweissmann.de/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] why should I use mono?
While I can't speak for the Mono team, nor for everyone, I don't see this as an either / or proposition. I'm working with Mono to gain alternative platforms for projects that were defined as C# / .NET framework implementations by the business. FRom a development deployment perspective, writing a WebService in Mono / .NET is significantly easier than doing them in Java. Remoting is also much easier. Java is still a great environment, and for some projects, it remains the best choice. There still isn't a usable Mono for the Mac OS X, so if you require OS X compatability, Java is your best option. In short, I don't think there is a unilateral why, there are a lot of little contributing reasons that you as a developer need to evaluate to the business, or productivity problem that you are trying to solve. Unfortunately, we as developers sometimes lose track of the concept of the 'best solution to a problem' in our advocacy of what we are comfortable with, or of what we want to learn next :-). Andy On Nov 7, 2003, at 6:29 AM, Evert Tigchelaar wrote: Hi, I read in an artical about mono. Why should developers should write code for the mono runtime instede of Java? Evert __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] yet another...OS X build problem
try replace libtool in your makefile with glibtool Andy On Oct 2, 2003, at 2:50 PM, Christopher Taylor wrote: That would mean nope. ranlib still hates me. it's not getting passed the right variable for -mode=MODE inorder to generate libs... not really sure how to work around this problem... On Thursday, Oct 2, 2003, at 13:07 US/Eastern, Bob Koss wrote: Does this mean that you got 0.28 to build on OS X? On 10/2/03 12:22 PM, Christopher Taylor [EMAIL PROTECTED] wrote: hey, found this link: http://lists.ximian.com/archives/public/mono-list/2003-February/ 012024.html while googling this morning. I'm having a similar problem with ranlib. Making all in utils /bin/sh ../../libtool --mode=link gcc -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -pthread -o libmonoutils.la mono-hash.lo mono-md5.lo mono-sha1.lo mono-logger.lo monobitset.lo strtod.lo -lpthread rm -fr .libs/libmonoutils.la .libs/libmonoutils.* .libs/libmonoutils.* ar cru .libs/libmonoutils.al mono-hash.lo mono-md5.lo mono-sha1.lo mono-logger.lo monobitset.lo strtod.lo ranlib .libs/libmonoutils.al *** Warning: inferring the mode of operation is deprecated. *** Future versions of Libtool will require -mode=MODE be specified. ranlib: warning: cannot infer operation mode from `.libs/libmonoutils.al' ranlib: you must specify a MODE Try `ranlib --help' for more information. make[3]: *** [libmonoutils.la] Error 1 ranlib isn't being passed the correct --mode [i guess this is a libtool problem?] wasn't sure if you had a fix for it [or if anyone else did for that matter]. Much thanks for the help! ct ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list -- Robert Koss, Ph.D. | Training, Mentoring, Contract Development Senior Consultant | Object Oriented Design, C++, Java www.objectmentor.com | Extreme Programming ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] RE: Mac X and latest cvs source
No, this is not the case. I have glib-2.0 installed and configured, correctly, that's not the issue. The error raised by configure isn't that the package isn't installed (pkg-config even knows about glib-2.0 and returns correctly). I happen to think that we are exposing a bug in either autogen.sh or configure. I've attached the corresponding errors for your entertainment :-). !-- log -- checking for pkg-config... /usr/local/bin/pkg-config ./configure: line 8619: syntax error near unexpected token `PKG_CHECK_MODULES(BASE_DEPENDENCIES,' ./configure: line 8619: `PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION)' !-- /log -- Since the log doesn't tell you the context, let's try looking closely at the relevant section of the configure that autogen.sh builds !-- snippet of configure -- 8618 ## Versions of dependencies 8619 GLIB_REQUIRED_VERSION=1.3.11 8620 8621 PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION) 8622 8623 GLIB_CFLAGS=`$PKG_CONFIG --cflags glib-2.0` 8624 GLIB_LIBS=`$PKG_CONFIG --libs glib-2.0` 8625 GMODULE_CFLAGS=`$PKG_CONFIG --cflags gmodule-2.0` 8626 GMODULE_LIBS=`$PKG_CONFIG --libs gmodule-2.0` !-- /snippet of configure -- The configure that was part of the pre .23 releases built fine. STarting with .24, configure started failing on this. As you can see the error itself is not on glib-2.0. Commenting out lines 8619 and 8621 from this configure will successfully build the mono exectuable, and it will run, though, I don't have an mcs on the machine so I obviously cannot get a fullbuild right now. I know next to nothing about shell scripting, so I've now pretty much exhausted my knowledge level on the subject. PKG_CHECK_MODULES would appear to be a function call, but I don't see it's definition using a grep of the directory doesn't show it being used anywhere else in the build system, so I'm guessing (of the wild ass variety) that this is a dependancy failure, but not one on glib-2.0. Hope this helps, Andy On Wednesday, August 20, 2003, at 09:56 AM, Paolo Molaro wrote: On 08/19/03 Matthieu Cormier wrote: ./autogen.sh --prefix=/usr/local This will complain about line 8056 -- PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION) comment out the line # PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION) in configure file This means you don't have glib-2.0 correctly installed. Without it you'll never get mono compiled. People suggest using Fink because it makes it easy to have this and other dependencies in place. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mac X and latest cvs source
Are you using Fink to do the installs or doing it manually? What I've found is that installing the packages from Fink (something I personally have issues with, /sw/) works best with Mono's build process. Doing it from the tarfiles seems to leave some settings not there. Like you, it's been my experience that there isn't something quite happy with the current Mono CVS or releases, and it's been true for three . releases now. I've gotten a little further than you have, but I'm getting a VAR_ARGS compiler error well into the source tree. Andy On Tuesday, August 19, 2003, at 10:12 AM, Matthieu Cormier wrote: Thanks for the response. If you want to help out, you should use mono from cvs, not a version several months old. Mono from cvs compiles fine on macosx (yes, we know the last released package doesn't). I've downloaded the latest source from cvs and unsuccessfully tried making the mono module. Below is a summary of what I tried to do to install. My main questions are: 1. What libtool is everyone using? Does it require a specific version? autogen.sh tries using a --version option which isn't available on the version I compiled and installed so I commented out that initial test. 2. Have I not installed glib properly? Why is pkg-config giving me the error displayed below? 3. Typing make in the mcs directory gives me a Bus error. I'm assuming that this is because there is no jit compiler on Mac and it is try to use mint. Is this correct? Thanks, M@ --- Begin of Install notes - checked out mono sources Tried ./autogen.sh --prefix=/usr/local in mono module wanted libtool dowloaded and extracted libtool-1.4.2.tar.gz setenv CFLAGS -no-cpp-precomp ./configure make make check 4 of 79 tests failed FAILED: mdemo-make.test dryrun.test hardcore.test mdemo-make.test sudo make install retried ./autogen.sh --prefix=/usr/local still wanted libtool looked at autogen.sh tried libtool --version ( didn't work ) commented out libtool test in autogen.sh retried ./autogen.sh --prefix=/usr/local Got Error message === checking for pkg-config... /usr/local/bin/pkg-config ./configure: line 8054: syntax error near unexpected token `PKG_CHECK_MODULES(BASE_DEPENDENCIES,' ./configure: line 8054: `PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION)' === looked at pkg-config --version 0.15 installed decided to install latest stable pkg-config 0.14 downloaded and extracted setenv CFLAGS -no-cpp-precomp ./configure make make check === All 11 tests passed === sudo make install retried ./autogen.sh --prefix=/usr/local Got Error message === checking for pkg-config... /usr/local/bin/pkg-config ./configure: line 8054: syntax error near unexpected token `PKG_CHECK_MODULES(BASE_DEPENDENCIES,' ./configure: line 8054: `PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION)' === I know I installed glib-2.0.7 but let's install the latest stable release downloaded and extracted glib-2.2.2.tar.gz from ftp.gtk.org setenv CFLAGS -no-cpp-precomp ./configure make make check 2 of 30 tests failed suod make install retried ./autogen.sh --prefix=/usr/local recieved same error message === checking for pkg-config... /usr/local/bin/pkg-config ./configure: line 8054: syntax error near unexpected token `PKG_CHECK_MODULES(BASE_DEPENDENCIES,' ./configure: line 8054: `PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 = $GLIB_REQUIRED_VERSION)' === NOTES: When running ./autogen.sh --prefix=/usr/local I get the following You should update your `aclocal.m4' by running aclocal running aclocal inside the directory does not eliminate this message, have never used aclocal before --- End of INstall notes- ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] MacOS X Mono Hackers...
I'm just now starting to really roll up my sleeves and get into the Mono on MacOS X code and I'm looking to find out who else is actively working on the OS X code, and to see where everyone else is at on it. Andy Satori Satori Associates, Inc. [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] MacOS X Mono build issue (0.25 from CVS)
After about a month off from anything mono related, I'm back to hacking on Mono for Mac OS X. Rebuilt a Mac OS X machine from scratch, built all the dependancies (no Fink (unix software belongs in /usr/local/ not in /sw)) I've gotten a build environment set back up. The problem is that 0.25 has reintroduced the _VA_ARGS__ compiler errors again. This came up once before in the 0.19 days, but I don't recall the solution. Below is the matching log. /monoburg.c:941:51: warning: __VA_ARGS__ can only appear in the expansion of a C99 variadic macro ./monoburg.c: In function `check_result': ./monoburg.c:941: `__VA_ARGS__' undeclared (first use in this function) ./monoburg.c:941: (Each undeclared identifier is reported only once ./monoburg.c:941: for each function it appears in.) ./monoburg.c:949:51: warning: __VA_ARGS__ can only appear in the expansion of a C99 variadic macro the line in question is actually using the g_warning() function call. Any body else recall the issue / solution? Andy Satori Satori Associates, Inc. [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mint --debug error
Ok, I've got some time to work through some issues with Mono and Mac OS X, so I'm starting to wade in. Before I go prowling through the code, anyone have a general direction to point for a 'Bus error' (that's everything it shows) for a 'mint --debug' command? Andy ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] OS X build weirdness
Oh, it works, up to a point. I'm more or less sitting on the OS X side until 0.25, when hopefully mini will be in the loop. Since mini appears to be the future direction of the mono project, and it's supposedly more portable, it would seem to be a better candidate for OS X than mint, which has some issue on OS X. Andy On Thursday, June 5, 2003, at 09:15 AM, Benjamin Reed wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trevor Strohman wrote: ** (/usr/bin/mcs.exe:24622): WARNING **: Could not find assembly System Can not open image /usr/bin/mcs.exe make[1]: *** [mcs.exe] Error 1 make: *** [all] Error 1 (I get that right after the makefile tries to fire up mcs.exe with mint for the first time). Is this supposed to work yet? Am I doing something wrong? I don't need it to even work that well, I'd just like to get to the point where mint can has enough standard library support to actually run some test code. You're basically as far as the OSX port gets (that's why mcs isn't in Fink ;) It's likely gonna need someone who understands both OSX programming and mono internals, which is not me, to get it working. - -- [ Benjamin Reed a.k.a. Ranger Rick ][ http://ranger.befunk.com/ ] You can scoff, Lister, that's nothing new. They laughed at Galileo. They laughed at Edison. They laughed at Columbo. Who's Columbo? The man with the dirty mac who discovered America. -- _Red Dwarf_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+30KGUu+jZtP2Zf4RAm1EAJ0WAhyMtjR2R8/GAiLLNIWT6uFj/ACfU3jc GFT4V/msfw1WcMdyiWBD6rg= =l42R -END PGP SIGNATURE- ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] regsvr32
The equivalent to regsvr32 in .NET is RegSvcs. However, that's for COM+ assemblies. In the Mono world, it would be useless to register a COM dll. You would want the equivalent of the GacUtil to load an assembly in the Global Assembly Cache. Andy On 3/14/03 12:26 PM, Paolo Molaro [EMAIL PROTECTED] pounded the keyboard to produce: On 03/13/03 Daniel Grigoras wrote: please, there is something similar with regsvr32.exe MyProfiler.dll(for Windows ),but in I have no idea what regsvr32.exe does. Linux ? How may I register a profiler (DLL) under Linux? In CVS , there are the equivalents of ICorProfilerInfo and ICorProfilerCallback ( profiler.c , profiler.h ..). Currently we have just an hard-coded profiler built-in in the mono runtime: the plan is to add an option to load dynamically a library that implements the profiling interface, but I didn't write the code to do that, yet. And, yes, the profiling interface is similar, but is not the same as in the MS runtime. lupus ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] regsvr32
Bonobo and COM+ are about as far apart in implementation as CORBA and COM are. That's not to say that System.EnterpriseServices couldn't be implemented to support Bonobo on Gnome boxes, but they would be incapable of say calling a remote object on a Windows COM+ based server. You could probably munge this all to work locally, but when you start down the path of COM+ interop, I think you create a large scale problem in managability. All that said, using .NET native assemblies and .NET remoting, you do get the benefit of being able to use your assembly assets throughout the enterprise despite the native host environment. Furthering that, if you absolutely must retain legacy COM+ interfaces (I do, I have a large legacy of VB6 COM interfaces that I must maintain through the transition) you can wrap those with SOAP webservices, acknowledge a minor performance hit, and then deploy using SOAP and WebServices thus eliminating the dependency on COM+. Andy On 3/14/03 2:01 PM, Bob Smith [EMAIL PROTECTED] pounded the keyboard to produce: At some point arn't we going to have some equivilent for Bonobo? On Fri, 14 Mar 2003, Andy Satori wrote: The equivalent to regsvr32 in .NET is RegSvcs. However, that's for COM+ assemblies. In the Mono world, it would be useless to register a COM dll. You would want the equivalent of the GacUtil to load an assembly in the Global Assembly Cache. Andy On 3/14/03 12:26 PM, Paolo Molaro [EMAIL PROTECTED] pounded the keyboard to produce: On 03/13/03 Daniel Grigoras wrote: please, there is something similar with regsvr32.exe MyProfiler.dll(for Windows ),but in I have no idea what regsvr32.exe does. Linux ? How may I register a profiler (DLL) under Linux? In CVS , there are the equivalents of ICorProfilerInfo and ICorProfilerCallback ( profiler.c , profiler.h ..). Currently we have just an hard-coded profiler built-in in the mono runtime: the plan is to add an option to load dynamically a library that implements the profiling interface, but I didn't write the code to do that, yet. And, yes, the profiling interface is similar, but is not the same as in the MS runtime. lupus ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] OS X build problems still
I have Mono built 0.23, that's not the problem. Once you have it running you get the following, which makes it pretty useless still for usage. I've been trying to trace back to find out why this is an issue though. [samwise:~] arsatori% mcs GLib: Cannot convert message: Conversion from character set 'UTF-8' to 'en_US' is not supported ** (/usr/local/bin/mcs.exe:5032): WARNING **: Using non-atomic functions! /usr/local/bin/mcs: line 2: 5032 Bus error /usr/local/bin/mint /usr/local/bin/mcs.exe $@ Andy On 3/13/03 7:49 PM, Benjamin Reed [EMAIL PROTECTED] pounded the keyboard to produce: James Fitzsimons wrote: Hi Benjamin, The reason I was trying to compile glibc was because it is a perquisite for Mono. Is there some way of specifying another libc (i.e. the Apple version) in the Mono configure stage? Is this a recent addition? It didn't need glibc as of 0.23... Doesn't seem very portable then. :) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Future of JIT
Woo! Seriously, I've been hacking on getting together a working OS X Mono environment off and on for a couple of months now, and this is a huge step in the right direction, thanks Paolo. Andy On Monday, February 3, 2003, at 02:05 PM, Paolo Molaro wrote: On 02/03/03 Piers Haken wrote: Hopefully when the new JIT engine is release, we will release some technical documents on it as well. Yeah that would be great. Maybe you or Paolo could give us a little teaser to tide us over until then? Maybe some of the basic algorithmic Ok, here is the scoop: I have mini (the codename for the new JIT) happily running and compiling methods on MacOSX to x86 native code with the wrong endianness! lupus / ducks :-) -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
