RE: [patch #6448] [MSVC 7/7] Add MSVC Support
> > I Forgot to answer some things... > > > My patches use the same host/build as MinGW when using MSYS, on the > grounds that the output from the MinGW tools and MSVC are compatible > (so same $host) and that MSYS is MSYS (same $build). That's also > how cccl has it (at least I think so...) Hmm.. but your compiler is a different one, and thus behaves different than mingw. I don't think it's a good idea to take the mingw triplet for something other than mingw. Who knows - if there is something out there that is capable of patching mingw binaries in some form, relying on code that only gcc creates (I know that sample is kind of unrealistic, but hey - I patch MSVC binary code ;)) - it would fail with you binaries. > > >>>The winnt was just the best that came to our ming, since > >> the > >>> result is plain win32 binaries. > > "winnt" is not the only kind of output from MSVC. So, why is winnt > better than win9x/winxp/win2k3 or whatever? And other tools also > target winnt. To sum it up, I think winnt is both too narrow and > too broad to be used as $host. Why not just parity? I don't support the 9x series of windows, and everything else is NT-kernel based, so I think winnt denotes all of NT4, 2000, XP, 2003, 2003R2, Vista and 2008 - that's what I intend. > > If you want to have a common name, mingw is it, that's what's used > to denote the win32 environment w/o compatibility layers. If you > want to go your own way, winnt is too generic. IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. > > That's just my view of things of course, but I have previously > been proven to have a distorted view. So, use the salt shaker > liberaly... Hehe, my opinion has been proven to be distorted too. So maybe discussing on this leads both of us somewhere :) Cheers, Markus > > >>> So really the host could be *- > >> interix* and > >>> target of parity is *-winnt*. > > Are interix binaries not in the posix subsystem? Or did you mean > *-interix* as $build and *-winnt* as $host? > > Cheers, > Peter
Re: Two small libltdl patches.
Peter O'Gorman wrote: > So, with the functions also removed from the header, ok? Fine by me -- but I can't give official approval. -- Chuck
Re: Two small libltdl patches.
Bob Friesenhahn wrote: > On Sun, 24 Aug 2008, Charles Wilson wrote: > >> But wasn't there a thread back in June where we explicitly added a bunch >> of argz functions, so that (a) we would be using the same file as >> gnulib, and (b) that file would have a complete argz implementation? > > I recall that it was decided that it was not necessary for the > implementation to be identical to gnulib and that the code should not > need to be updated unless it is found to be broken. I just went back and re-read the argz threads on bug-libtool. The two functions were added back in February, the June thread then decided that libtool could keep its own argz and only have the functions it needs, while gnulib's could "evolve along glibc's". Now that I look at the patch again, I see that I forgot to remove the functions from argz_.h :) So, with the functions also removed from the header, ok? Peter -- Peter O'Gorman http://pogma.com
Re: Two small libltdl patches.
On Sun, 24 Aug 2008, Charles Wilson wrote: But wasn't there a thread back in June where we explicitly added a bunch of argz functions, so that (a) we would be using the same file as gnulib, and (b) that file would have a complete argz implementation? I recall that it was decided that it was not necessary for the implementation to be identical to gnulib and that the code should not need to be updated unless it is found to be broken. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Two small libltdl patches.
Peter O'Gorman wrote: > On systems without argz we were exporting unmangled symbols argz_count > and argz_add from libltdl. Not really a good idea. Rather than mangle > the names, since we do not use either function, they were removed. But wasn't there a thread back in June where we explicitly added a bunch of argz functions, so that (a) we would be using the same file as gnulib, and (b) that file would have a complete argz implementation? Doesn't your patch fork our copy again? (Or have I missed some intervening decisions/development)? -- Chuck