Re: Re[2]: 64-bit windows version?
On Wed, 2007-06-20 at 07:34 +0400, Bulat Ziganshin wrote: > Hello skaller, > > Tuesday, June 19, 2007, 8:15:19 PM, you wrote: > >> > are you plan to implement 64-bit windows GHC version? > > > Why do you need mingw? What's wrong with MSVC++? > > really! Simon, how about unregisterised build? > > skaller, is *free* 64-bit msvc (or any other windows c++ compiler) available? Visual Studio Express is a Visual Studio 2005 IDE system for XP with some features disabled, the disabled features include interactive debugging, help, online news/blog stuff, etc: advanced IDE features. AFAIK the compilers are intact and can be used on the command line as well as from the IDE. I think you do need to download the platform SDK separately though. AFAIK on x86_64 platform, VS is a 32 bit program, as are the compilers, but they can generate 64 bit code (the 32 and 64 bit compilers are separate executables and run in distinct environments .. ) One thing to watch though: embedded assembler is gone in new MSVC++ compilers (due to multi-arch support I guess). However assembler works in 64 bit, Ocaml 64 bit for Windows uses it. -- John Skaller Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: 64-bit windows version?
Hello skaller, Tuesday, June 19, 2007, 8:15:19 PM, you wrote: >> > are you plan to implement 64-bit windows GHC version? > Why do you need mingw? What's wrong with MSVC++? really! Simon, how about unregisterised build? skaller, is *free* 64-bit msvc (or any other windows c++ compiler) available? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: > Bulat Ziganshin wrote: > > Hello glasgow-haskell-users, > > > > are you plan to implement 64-bit windows GHC version? > > The main thing standing in the way of this is the lack of a 64-bit port of > mingw. Why do you need mingw? What's wrong with MSVC++? -- John Skaller Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Jun 19, 2007, at 4:05 AM, Simon Marlow wrote: Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/ local/lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall?... That is why I think your idea was good: put everything into distinct directories. We are not intending to build-in any particular knowledge about where shared libraries are to be installed - that's up to the packager. Definitely. It would be non-portable if GHC baked the install directory into the shared library install_name (using libtool lingo) whenever a programmer (or Cabal) invoked ghc --make. With one exception - we have to pick a default for the .tar.bz2 binary distributions (and 'make install'), and the only default that makes sense is to install the shared libraries in the standard location, /usr/local/lib. Otherwise the system will not find them, and GHC itself will not run (assuming it is dynamically linked). You don't get good uninstall support, but that's always been the way if you don't use the system package manager. I advocated putting everything in /usr/local/lib/ghc/ghc-$(version) earlier. The dynamic-library system used for ghc-6.4 on OS X worked fine; do you remember any problems when that was put together? Stefan O'Rear seemed against flooding /usr/local/lib with ghc- libraries--I'll admit my own /usr/local/lib is a bit messy even considering I use 'port' for quite a few programs--but also argued that the dynamic libraries should not go in the /usr/local/lib/ghc-$ (version). The de-facto standard for systems that have C or C++- compliant dynamic libraries seems to be: shared libraries go in: /usr/local/lib static libraries or system-specific libraries go in: /usr/local/lib/$(system)/$(system_version) or $(build)/$(system_version) So for nhc98, the static libraries are in /usr/local/lib/nhc98/$ (build); for yhc, the .ycr files are in /usr/local/lib/yhc/packages/ yhc-base/$(yhc_version); for felix the .flx files (as source code) are in /usr/local/lib/felix/$(felix_version)/lib; for ocaml, the .cmx and .cmi files go in /usr/local/lib/ocaml; but for chicken-scheme the dynamic libraries (only really usable through the chicken interface but definitely "pure" C in the end) are in /usr/local/lib. I should not neglect to say the same goes for python, although . The one exception seems to be for gcc's libstdc++, which has a symlink in the same directory as the static libraries. Following what I--perhaps mistakenly--called the 'de facto' standard, if ghc dynamic libraries are callable from C (they are), then the dynamic libraries should go into /usr/local/lib. I would highly suggest that symlinking an un- versioned name to each version would create a mess, so the library names should only follow the real version. Stefan does have a point, so the default installer might place dynamic libraries in a user library directory such as $(home)/lib--a real consideration for students and others who work on a large shared system where the sysadmin does not want to support yet another language installation. What seems backwards (to me) are the Haskell programs: it would be fine if the standard install for program static libraries and interfaces went into the ghc-$(version) directory but they don't and when we had dynamic libraries on OS X they followed the static library convention: each program is installed into /usr/local/lib/$ (program) or $(program)-$(version). Some programs place libraries directly into the program directory while others place the libraries under a $(haskell_compiler)-$(haskell_compiler_version) directory. This duplicates the ghc system of /usr/local/lib/ghc-$(version) for each Haskell program and creates a real mess--more so than other languages. I agree, this is not really GHC's problem but the ghc location might help, which is why I suggested /usr/local/lib/ghc/ghc-$ (version). It might even be extendable to all of Haskell: ghc should go into /usr/local/lib/haskell/ghc-$(version), so, say, yhc could go into /usr/local/lib/haskell/yhc and the installed programs would go into /usr/local/lib/haskell/$(compiler). Much cleaner and much easier for a package system to manage. I have written too much on this, so I'll shut up--whatever you decide is fine; I'll fix the install script to create a PackageMaker .pkg following whatever you decide and post it if you want it. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64-bit port of mingw. The latest status update I could find is here: http://sourceforge.net/mailarchive/message.php?msg_id=460D8FC1.64E689DB%40dessent.net Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
64-bit windows version?
Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/local/lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the uninstall of that version of the library would fail but for unix systems _only_ if you also have another program using at while you are doing the uninstall. So if you did not break everything on each install, eventually you have a complete mess of different versions of GHC libraries in /usr/local/lib that may have no current use but at one time were used for several GHC-Haskell-based programs that have now been upgraded to use something different. Hopefully those who distributed the binary programs adopted a convention of using the full version of the library instead of symlinking libHSrts_dyn-6.6.1 to libHSrts_dyn, or as a user several of your older programs might break after a later one installed a new version of the library and symlinked that the new version... That is why I think your idea was good: put everything into distinct directories. We are not intending to build-in any particular knowledge about where shared libraries are to be installed - that's up to the packager. With one exception - we have to pick a default for the .tar.bz2 binary distributions (and 'make install'), and the only default that makes sense is to install the shared libraries in the standard location, /usr/local/lib. Otherwise the system will not find them, and GHC itself will not run (assuming it is dynamically linked). You don't get good uninstall support, but that's always been the way if you don't use the system package manager. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
