From: Keith M. <kei...@us...> - 2009-04-20 18:29:13
|
On Sunday 19 April 2009 00:19:11 Charles Wilson wrote: > >> Note #2: Why did you need to roll your own libiconv DLL? Was > >> there something wrong with the existing > >> libiconv-1.11-1-bin.tar.bz2 > >> libiconv-1.11-1-dll.tar.bz2 > >> packages? > > > > As you mentioned elsewhere in your email, these are part of > > MSYS, which requires that MSYS is installed and being used to > > run GCC for GCC to work. > > Uhm, no. These are the one that depend on MSYS: > > libiconv-1.11-MSYS-1.0.11-1-src.tar.bz2 > libiconv-1.11-MSYS-1.0.11-1.tar.bz2 > > The ones I mentioned before are plain, native, mingw ports (well, > not "MinGWPorts" exactly). They were *built* from within an MSYS > environment -- but that's no different than building from a > cygwin- or linux- hosted cross environment, as you did when > building your version. Yeah. We've mentioned this before: listing this pair libiconv-1.11-1-bin.tar.bz2 libiconv-1.11-1-dll.tar.bz2 within the "MSYS Supplementary Tools" package set is just plain wrong. While they may have been needed initially to support tools which do belong there, the DLL package is *already* a prerequisite for the gencat tool from mingw-catgets-1.0-dev.tar.gz, which is listed among the "User Contributed" package collections. > >> HOWEVER: I still have a question about the appropriate path > >> for pre-compiled "native" (e.g. not MSYS) packages. > > > > Exactly. We've always had all native MinGW packages (non-MSYS) > > based in /mingw, with no dependencies outside of /mingw, and I > > think we should have a very good reason to change this. > > Right. That's not at issue. It isn't an issue, at all; it is *convenient*, (for mass production of binary releases), to distribute for installation into the /mingw tree, and I see no reason to change that. > I'm only talking about mingw ports (not "MinGWPorts" necessarily) > -- but native, win32, no-MSYS-required builds of various > libraries. Naturally, just the barest minimum (in keeping with > the minimal nature of the whole beast) of libraries needed for > runtime support of gcc itself. Now, libiconv and gettext are a > little odd: on the one hand, they (their DLLs, that is) are > needed *at runtime* by the gcc executables themselves [*]. That > means these mingw-native DLLs are on the "MinGW" distribution > side of the fence. On the other hand, they (their utilities, > import libs, static libs, header files, data files, and m4/ > stuff) are also part of an MSYS-hosted, mingw-native-target > autotool development environment. That makes them (the native, > win32 versions) also part of the "MSYS" distribution. Again, this is largely a matter of convenience; it is convenient to run these tools in a MSYS hosted environment, (in particular, those which do require support from MSYS programs). However, there is no reason why the native DLLs, and even the native tools shouldn't be installed into the MinGW tree, rather than an MSYS specific path. > So, the native, win32, mingw-only, no-msys-in-sight version of > the libiconv DLL...is needed by both "regular" msys-less gcc by > itself, but also by an msys-hosted mingw-target development > environment elaborated with the associated utilities, import > libraries, static libs, headers, etc. Those two uses should be > complementary, not conflicting. Agreed. > We also already have mingw-target versions of the autotools. > These are the ones listed in my previous email. They are part of > the MSYS (-host, mingw-target) environment and I am not proposing > to change that. However, none of those binaries (EXEs or DLLs) > link against or need in any way the msys.dll. All I'm proposing > is that these (mingw-native, win32-only, no-msys-dll-in-sight) > tools be *installed* into /mingw by default -- even if (with > exactly one exception) they are not "part of" the default "MinGW" > distribution. They are part of the MSYS supplement. Seems to me that that would already be achievable, if the distribution tarballs had "usr/local/" removed from their package root; then the choice can be made at installation time, by making the appropriate "cd" choice, prior to extracting the tarball. > I *ALSO* think it's possible that the libiconv and gettext > packages targeted for mingw should be built with Bruno Haible's > "relocation" support turned on, but that's another issue, and one > that will require more thought than I've yet put into it. I don't know exactly what effect that might have; I just built libiconv-1.13 with "--enable-relocatable --disable-nls", and with prefix set to `cd /mingw; pwd -W`, then installed into a completely different staging directory; iconv.exe seems, with very limited testing, to behave as expected. (The only issue I encountered was that "install-strip" failed, (but bare "install" was ok); likely a missing "$(EXEEXT)" in some Makefile.in). -- Regards, Keith. |