From: James M. D. <mdu...@ya...> - 2002-08-30 20:31:59
|
Dear fellow hackers, I am working on putting my packages on sourceforge right now, https://sourceforge.net/project/showfiles.php?group_id=19878 I still have not converted all of my packages to the high standards that I preach, this of course makes me a hypocrite in one aspect. It is not easy to put all the work into making the legal aspects of software compliant. the social ones as well. I hope that you will accept my general apologie for any insults that I may have inflicted on you. libiconv is ready for scrutiny, note that the full changes to the changelog are missing, but I have to get going. So feel free to complain that I to will leave out parts of the GPL required documenation while posting a intermediate step. This is just a work in progress. So, I hope to hear from you any attempts at compiling, I will be uploading the fully compiled glib this weekend as well if anyone wants an snapshot. Hopefully all the changes will be in a distributable state, I am working on the simplist debian header right now. Best regards and happy hacking. Mike PS : I will be spending some time away from the computer, so it can take a full 48hrs before my next update. ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Greg C. <chi...@mi...> - 2002-08-31 00:15:57
|
[snipped other mailing lists that I don't belong to] James Michael DuPont wrote: > > libiconv is ready for scrutiny, note that the full changes to the > changelog are missing, but I have to get going. So feel free to > complain that I to will leave out parts of the GPL required > documenation while posting a intermediate step. This is just a work in > progress. Please help me understand the motivation for changing libiconv. I thought the libiconv sources already built successfully with MSYS, as well as with linux of course. Have you found defects in libiconv that need correction? Are you enhancing the library in some other way? |
From: Elizabeth B. <sog...@ya...> - 2002-08-31 02:54:56
|
Greg Chicares <chi...@mi...> writes: > Please help me understand the motivation for changing libiconv. I > thought the libiconv sources already built successfully with MSYS, > as well as with linux of course. Have you found defects in libiconv > that need correction? Are you enhancing the library in some other > way? Yes I noticed how easy libiconv's configure built a DLL. I've since begun studying autoconf et. al. in order to figure out how the libiconv went so smoothly. Is this a normal part of the auto* tools and the newer ones support mingw->DLL? Or does the maintainer of libiconv have a very nice suite of macros? Basically, I'd like to modify libxml2 so it's configure, too, can build a DLL out-of-the-box. Is there anything special I should look for? Thank you, Elizabeth |
From: Greg C. <chi...@mi...> - 2002-08-31 04:48:27
|
Elizabeth Barham wrote: > > Greg Chicares <chi...@mi...> writes: > > > Please help me understand the motivation for changing libiconv. I > > thought the libiconv sources already built successfully with MSYS, > > as well as with linux of course. Have you found defects in libiconv > > that need correction? Are you enhancing the library in some other > > way? > > Yes I noticed how easy libiconv's configure built a DLL. > > I've since begun studying autoconf et. al. in order to figure out how > the libiconv went so smoothly. > > Is this a normal part of the auto* tools and the newer ones support > mingw->DLL? Or does the maintainer of libiconv have a very nice suite > of macros? I don't even know enough to say "I think so" without fear of misleading you. > Basically, I'd like to modify libxml2 so it's configure, too, can > build a DLL out-of-the-box. Is there anything special I should look > for? I have built libxml2 as a dll using mingw version 2.95.2-1 (I know that's real old) and am now using it in a production release of our application. A few points: You need to have '-lwsock32' in LDFLAGS. (Or remove the stuff that needs that library--I though it easier not to.) There are some things like #if defined(WIN32) && (defined(_MSC_VER) || defined(__BORLANDC__)) that want changing--instead, here, I used #if defined(__WIN32__) Here's another one: ! #ifdef _MSC_VER /* MS C-runtime has functions which can be used in order to determine if a given floating-point variable contains NaN, (+-)INF. These are Since mingw uses the msvc rtl, you can change that to: #if defined(_MSC_VER) || defined(__MINGW32__) Similarly, #if defined(_MSC_VER) || defined(__MINGW32__) /* We don't use trio when compiling under MSVC. This is not because trio I couldn't get auto-import to work with one function pointer--to xmlNew() IIRC--so I fell back on the old reliable #ifndef LIBXML_DLL_IMPORT # if defined(__WIN32__) # if defined(IN_LIBXML) /* Build dll. */ # define LIBXML_DLL_IMPORT __declspec(dllexport) # elif defined(LIBXML_USE_DLL) /* Use dll. */ # define LIBXML_DLL_IMPORT __declspec(dllimport) # else /* Neither build nor use dll. */ # define LIBXML_DLL_IMPORT # endif /* Neither build nor use dll. */ # else /* Not defined(__WIN32__) */ # define LIBXML_DLL_IMPORT # endif /* Not defined(__WIN32__) */ #endif /* Not defined(LIBXML_DLL_IMPORT) */ approach. Perhaps that's not necessary with a newer version of mingw, but I think it can't be harmful. Since I don't know much about automake or libtool, I just added a few lines of dlltool stuff to the makefile. There's probably a better way. A coworker is offering these (and other) patches to the libxml maintainer. The patch is 49 K; I'll email it to you if you like. |
From: Paul G. <pga...@at...> - 2002-09-01 03:10:54
|
On 31 Aug 2002 at 0:40, Elizabeth Barham wrote: > Greg Chicares <chi...@mi...> writes: > > I don't even know enough to say "I think so" without fear > > of misleading you. > > Hi Greg, > > Thank you for the information, however I have successfully built > libxml2 in the past using a custom makefile but I recently downloaded > the Debian version of Mingw (that is, the compiler produces code > suitable for running in Win32) and it build libiconv without much > problems. Libxml2, OTOH, was built as a static library and I'm > wondering what the difference is. > > To re-phrase my question, since libiconv worked so well in the > environment so as to produce a DLL, are newer versions of autoconf > pre-configured to work with Mingw or is there something special about > libiconv? Most often the case is something special about the actual configuration process, ie. modifications to autoconf script(s?), generated makefiles, etc. Those sorts of things are usually dependent on the distribution being used. Some distributions do accommodate Mingw specifically. Others can deal with Mingw development (build-wise) with little or no modifications "out-of-the-box". Even so, it is the actual generation/configuration process itself ("autoconf generated ./configure" or 'makefile" generated doesn't really matter*...) that determines whether something can be built "out-of-the-box" or not. [*exception, within Mingw development environment under "Windows", does not include any "Modified for Windows command shell aside from standard cmd.com/command.com provided with your particular Windows OS".] If you are wondering how many distributions are set up for Mingw, then that number is not really known. For the most part I just give it a try (test what was provided out-of-the-box) and hope it has already been modified to support a build within the Mingw development environment. "Cutting to the chase", rule-of-thumb, if a distribution is already set up to support msvc/c++, there is very good chance it can be built under Mingw development environment with "little to no" modifications. Paul G. |
From: Elizabeth B. <sog...@ya...> - 2002-08-31 05:40:44
|
Greg Chicares <chi...@mi...> writes: > I don't even know enough to say "I think so" without fear > of misleading you. Hi Greg, Thank you for the information, however I have successfully built libxml2 in the past using a custom makefile but I recently downloaded the Debian version of Mingw (that is, the compiler produces code suitable for running in Win32) and it build libiconv without much problems. Libxml2, OTOH, was built as a static library and I'm wondering what the difference is. To re-phrase my question, since libiconv worked so well in the environment so as to produce a DLL, are newer versions of autoconf pre-configured to work with Mingw or is there something special about libiconv? > Since I don't know much about automake or libtool, I just added a > few lines of dlltool stuff to the makefile. There's probably a > better way. There's a book available on the web that addresses libtool, autoconf and automake: <http://sources.redhat.com/autobook/> I've been going through it trying to understand more of these tools. I have been using them for years but only lately have I needed to peer into them. libtool is very nice considering all it does (it's new to me!). > A coworker is offering these (and other) patches to the libxml > maintainer. The patch is 49 K; I'll email it to you if you like. I would certainly like to look at it, thank you. Elizabeth |
From: Tor L. <tm...@ik...> - 2002-09-01 00:11:47
|
Elizabeth Barham writes: > To re-phrase my question, since libiconv worked so well in the > environment so as to produce a DLL, Hmm, but libiconv's configure.in doesn't contain the magic AC_LIBTOOL_WIN32_DLL line that I thought was necessary to enable DLL builds? Plus there were also some other problems I can't remember right now that, at the time I needed libiconv, cause me to do it the easy way and use the provided MSVC Makefiles instead... --tml |
From: Earnie B. <ear...@ya...> - 2002-09-01 00:18:22
|
Earnie Boyd wrote: > Elizabeth Barham wrote: > > > > > To re-phrase my question, since libiconv worked so well in the > > environment so as to produce a DLL, are newer versions of autoconf > > pre-configured to work with Mingw or is there something special about > > libiconv? > > That would be newer versions of libtool, not autoconf. And actually, it would be due to the /etc/config.site file and the version of libtool that is being used. I supplied default values for the libtool configuration to supply more correct values that libtool guessed. Earnie. |
From: Earnie B. <ear...@ya...> - 2002-09-01 00:18:32
|
Elizabeth Barham wrote: > > To re-phrase my question, since libiconv worked so well in the > environment so as to produce a DLL, are newer versions of autoconf > pre-configured to work with Mingw or is there something special about > libiconv? That would be newer versions of libtool, not autoconf. Earnie. |
From: James M. D. <mdu...@ya...> - 2002-08-31 10:44:21
|
--- Greg Chicares <chi...@mi...> wrote: > [snipped other mailing lists that I don't belong to] > > James Michael DuPont wrote: > > > > libiconv is ready for scrutiny, note that the full changes to the > > changelog are missing, but I have to get going. So feel free to > > complain that I to will leave out parts of the GPL required > > documenation while posting a intermediate step. This is just a work > in > > progress. > > Please help me understand the motivation for changing > libiconv. I thought the libiconv sources already built > successfully with MSYS, as well as with linux of course. > Have you found defects in libiconv that need correction? > Are you enhancing the library in some other way? I dont want to change it, just compile all the packages needed for DIA under mingw32 under debian. iconv,gettext, glib, gtk, pango, bonobo .... and others. If you know of anyone who has ported all of these to mingw32 under linux, and has any downloads I will use them. I just want to have a proper set of sources and script for easily compiling this stuff. The current distribution of DIA for w32 is a mess. (And for libiconv as well, there are like 6-7 different distos of it!) Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Greg C. <chi...@mi...> - 2002-08-31 17:07:40
|
James Michael DuPont wrote: > > --- Greg Chicares <chi...@mi...> wrote: > > [snipped other mailing lists that I don't belong to] > > > > James Michael DuPont wrote: > > > > > > libiconv is ready for scrutiny, note that the full changes to the > > > changelog are missing, but I have to get going. So feel free to > > > complain that I to will leave out parts of the GPL required > > > documenation while posting a intermediate step. This is just a work > > in > > > progress. > > > > Please help me understand the motivation for changing > > libiconv. I thought the libiconv sources already built > > successfully with MSYS, as well as with linux of course. > > Have you found defects in libiconv that need correction? > > Are you enhancing the library in some other way? > > I dont want to change it, just compile all the packages needed for DIA > under mingw32 under debian. > > iconv,gettext, glib, gtk, pango, bonobo .... and others. > > If you know of anyone who has ported all of these to mingw32 under > linux, and has any downloads I will use them. > > I just want to have a proper set of sources and script for easily > compiling this stuff. The current distribution of DIA for w32 is a > mess. > > (And for libiconv as well, there are like 6-7 different distos of it!) I share the frustration you express here and in your 'Will the real libiconv please stand up!' post sent about five minutes before. I'm maintaining a GPL application for win32. I support cygwin, but use mingw by preference because the binaries run faster. To build with mingw, developers need bzip2 tar make cp ls mkdir mv rm wc md5sum echo date patch diff sed and for years I've been maintaining a list of win32 ports that we've found to work, from several different sources. If each of those fifteen tools has half a dozen subtly different ports, that's 6^15 ways for something to go wrong--so we 'md5sum --check' the tools in the default makefile target. It would probably have been much easier to use cygwin tools exclusively. That's just not the way we evolved, but it might have saved an awful lot of trouble finding various native win32 ports and selecting among them. Still, that's not ideal. 'sed' is a nasty example: its 3.02 version has some version we really wanted (forget what exactly), but has a defect that tries to allocate an unbounded amount of memory in certain cases. We found various ports that all return '3.02' with '--version', but they behave differently. Some had this defect, and some had other defects. One was actually a 16-bit port that ran very slowly and did nasty things if it crashed. Some had source; others didn't. The cygwin 'sed' didn't work for us in all cases either. But that story has a happy ending. Version 3.02.80 does everything we need. With MSYS (and presumably cygwin) you just download the tarball from gnu.org and $ ./configure $ make The lesson for me was: don't look for a port--just build the source. I guess people in the *nix world already knew that. Many tools and libraries can use that approach. They might not need any platform-specific stuff, or such stuff might already be in place for win32. Some need a little help--for instance, libxml2 knows about cygwin but not mingw. We built libxml2 with mingw, but instead of putting the dll on some webpage, we sent the patches to the maintainer. There are too many pointless forks. Yet with libiconv, it's my impression that $ ./configure $ make works with MSYS, at least in the sense that it compiles; I don't recall whether I tried 'make test'. So I wonder whether you really need to do any work to get it to compile with mingw. Perhaps you're using a different shell? Not CMD.EXE I hope. |
From: James M. D. <mdu...@ya...> - 2002-08-31 18:26:22
|
--- Greg Chicares <chi...@mi...> wrote: > James Michael DuPont wrote: > > > > --- Greg Chicares <chi...@mi...> wrote: > > > [snipped other mailing lists that I don't belong to] > > > > > > James Michael DuPont wrote: > > > > > > > > libiconv is ready for scrutiny, note that the full changes to > the > > > > changelog are missing, but I have to get going. So feel free to > > > > complain that I to will leave out parts of the GPL required > > > > documenation while posting a intermediate step. This is just a > work > > > in > > > > progress. > > > > > > Please help me understand the motivation for changing > > > libiconv. I thought the libiconv sources already built > > > successfully with MSYS, as well as with linux of course. > > > Have you found defects in libiconv that need correction? > > > Are you enhancing the library in some other way? > > > > I dont want to change it, just compile all the packages needed for > DIA > > under mingw32 under debian. > > > > iconv,gettext, glib, gtk, pango, bonobo .... and others. > > > > If you know of anyone who has ported all of these to mingw32 under > > linux, and has any downloads I will use them. > > > > I just want to have a proper set of sources and script for easily > > compiling this stuff. The current distribution of DIA for w32 is a > > mess. > > > > (And for libiconv as well, there are like 6-7 different distos of > it!) > > I share the frustration you express here and in your > 'Will the real libiconv please stand up!' post sent > about five minutes before. > > I'm maintaining a GPL application for win32. I support > cygwin, but use mingw by preference because the binaries > run faster. To build with mingw, developers need > bzip2 tar make cp ls mkdir mv rm wc > md5sum echo date patch diff sed > and for years I've been maintaining a list of win32 ports > that we've found to work, from several different sources. > If each of those fifteen tools has half a dozen subtly > different ports, that's 6^15 ways for something to go > wrong--so we 'md5sum --check' the tools in the default > makefile target. Cool idea! I just had to do that myself to figure out the differences between some of my own files. > > It would probably have been much easier to use cygwin > tools exclusively. That's just not the way we evolved, > but it might have saved an awful lot of trouble finding > various native win32 ports and selecting among them. Well, cygwin is always very easy to use. I have been learning alot while compiling for windows under linux-> > But that story has a happy ending. Version 3.02.80 does > everything we need. With MSYS (and presumably cygwin) > you just download the tarball from gnu.org and > $ ./configure > $ make > The lesson for me was: don't look for a port--just build > the source. I guess people in the *nix world already > knew that. Thats what I have been doing, but have reproduced some of the porting done by the gnuwin32 guys first. > but not mingw. We built libxml2 with mingw, but instead > of putting the dll on some webpage, we sent the patches > to the maintainer. There are too many pointless forks. of course if I get anything of value, I will submit it to the owners. > > Yet with libiconv, it's my impression that > $ ./configure > $ make > works with MSYS, at least in the sense that it compiles; Hmm, I started with cygwin, then went to msys/mingw32 under wink2k. The ports that I used first were the gnuwin32 for gettext and libiconv. > I don't recall whether I tried 'make test'. So I wonder > whether you really need to do any work to get it to > compile with mingw. Perhaps you're using a different > shell? Not CMD.EXE I hope. My original attempt at compiling started with a recompilation inside of mingw32. I have posted my patches to that list, they are on http://introspector.sourceforge.net/dia/gettext-0.10.40.diff http://introspector.sourceforge.net/dia/libiconv-1.7.src.diff So, then I took that, went to debian and installed the www.libsdl.org mingw32 port, and now have compiled them as well as glib under linux for windows. I am creating now a debian source package out of the libiconv sources so that it will compile directly from apt. I hope to have something by next weekend that is usable.. My computer time is getting limited by that fact that my girlfriend just moved in, I need to take the time for her as well!! Best regards, mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: stefan <st...@lk...> - 2002-08-31 01:29:48
|
On Fri, 30 Aug 2002, James Michael DuPont wrote: > Dear fellow hackers, Hello! > I am working on putting my packages on sourceforge right now, > https://sourceforge.net/project/showfiles.php?group_id=19878 > I still have not converted all of my packages to the high standards > that I preach, this of course makes me a hypocrite in one aspect. The 'libiconv' library "port" for MinGW32 has always been maintained at the 'mingwrep' project on sourceforge. <http://sourceforge.net/project/showfiles.php?group_id=7382> Too bad we are doing duplicate work... Cheers, st...@lk... |
From: James M. D. <mdu...@ya...> - 2002-08-31 10:39:35
|
--- stefan <st...@lk...> wrote: > On Fri, 30 Aug 2002, James Michael DuPont wrote: > > > Dear fellow hackers, > > Hello! > > > I am working on putting my packages on sourceforge right now, > > https://sourceforge.net/project/showfiles.php?group_id=19878 > > I still have not converted all of my packages to the high standards > > that I preach, this of course makes me a hypocrite in one aspect. > > The 'libiconv' library "port" for MinGW32 has always been maintained > at the 'mingwrep' project on sourceforge. > > <http://sourceforge.net/project/showfiles.php?group_id=7382> > > Too bad we are doing duplicate work... > Wait! First of all I am talking about a mingw32 under debian, and second of all, please excuse that I overlooked your particular port, because there is no clear guidelines for the user as to which of the MANY ports he should use. I have been complaining about this all the time, I dont want to have to scrouge the net trying to find all the sources that I need to duplicate a port. That is why I have been complaining about the section 3 of the GPL. That states that all the sources and lib that are not part of the system have to put placed in the same place as the binaries. If people would follow the guidelines layed down by the FSF, then we would not have these problems. For example, the Dia installer does not have all the sources code of all the modules with it. The pw32 just has binaries, but the source code is missing. http://sourceforge.net/projects/pw32/ lets look for iconv : http://sourceforge.net/projects/libiconv/ -- This is from Haible http://savannah.gnu.org/projects/libiconv -- Oh another one! http://gettext.sourceforge.net/ -- another port! http://sourceforge.net/projects/mingwrep/ -- Your Package http://www.gnu.org/software/libiconv/ -- The GNU Package http://sourceforge.net/projects/gnuwin32/ -- The One I used http://www.gimp.org/~tml/gimp/win32/downloads.html -- Contains links to the gnu package, but not to yours. http://sourceforge.net/projects/gettext/ -- And the gettext. http://cygwin.com/cgi-bin2/package-cat.cgi?file=libiconv/libiconv-1.8-2-src&grep=iconv CYGWIN also has a port! So we have a least six different distributions, before we go into the gettext. Now, how am I to know what to use? I will try your package under mingw32 under Debian. So I just grabbed one of them an started to compile, even If your might have been newer. Let me tell you that I am just trying to get all the sources in one spot for the DIA recompilation for windows under mingw32/debian. I also want to setup some build environment that is easy to reproduce the binaries from and setup a strictly GPL compliant distribution of the entire sources. In the end, I want to a set of debian source packages that can be compiled using apt-source/dpkg for windows without any tweaking. As I said, I will try out your package, the only reason I posted this unfinished package was so that someone else can try to compile it. I hope that we can consolidate all these versions floating around into a single and consistent set of packages, you must admit that It is very confusing!!! If the sources had been at the DIA site, then I would have used thiers, or at the GIMP/GTK port. You guys need to fight is out as to WHO is the REAL slim shady! Will the real "libiconv" please stand up? Please stand up! Then we need to have a link on each of these projects as to who is doing what. Believe me, I dont want to spend any more time than needed on this at all! Maybe a WEBRING would be best, at least you all have each others names, now please start talking, agree on a standard disclaimer about where to go to get the newest version, who is doing what. Best regards, Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Tor L. <tm...@ik...> - 2002-09-01 00:02:49
|
James Michael DuPont writes: > lets look for iconv : > http://sourceforge.net/projects/libiconv/ -- This is from Haible > http://savannah.gnu.org/projects/libiconv -- Oh another one! > http://gettext.sourceforge.net/ -- another port! > http://sourceforge.net/projects/mingwrep/ -- Your Package > http://www.gnu.org/software/libiconv/ -- The GNU Package > http://sourceforge.net/projects/gnuwin32/ -- The One I used > http://www.gimp.org/~tml/gimp/win32/downloads.html -- Contains links to > the gnu package, but not to yours. "The gnu package" being libiconv's official home, so of course there is a link to that page??? > http://sourceforge.net/projects/gettext/ -- And the gettext. > > http://cygwin.com/cgi-bin2/package-cat.cgi?file=libiconv/libiconv-1.8-2-src&grep=iconv > So we have a least six different distributions, Not all of those are binary distributions. > Now, how am I to know what to use? This has indeed been sometimes a problem for me too, for this and other packages. Something needs to be done, and I will gladly start by dropping my binary "distribution" of libiconv and instead point to one of the others. Probably the http://gettext.sourceforge.net/ one, as it has a DLL (instead of a static archive), and with the same name as I have used, and there thus won't be any change visible to the users of the DLL. As an excuse for having an own binary "distribution" of libiconv I can just say that when I first needed it, I couldn't find a suitable binary Win32 distribution to use. But things now have changed. For me, an ideal binary distribution of a library for Win32 should fill the following criteria: - Unless the library is very small, it should be built as a DLL - If the library's API and ABI is guaranteed to only get extended, and never to change incompatibly, the DLL name need not be versioned. Otherwise a version number should be included in the DLL name. (Note that the version number in the DLL name need not have any relationship to the software's version number as a whole, but can be similar to what's used in ELF shared library names.) - If you do use versioning in the DLL name, increase he version number only if you introduce backward incompatibilities. Not if you just add interfaces. - The import library need not, and should not in most cases, have versioning in its name. Rationale: On ELF systems, you typically have: libfoo.so -> libfoo.so.x libfoo.so.x No import libraries on ELF, but symlinks, the end result being that you link with -lfoo. Correspondingly, on Win32, you should also link with -lfoo (or foo.lib), and this import library then links to libfoo-x.dll (or whatever naming convention you use; libtool uses that.) - The DLL should be useable both from gcc- and MSVC-compiled code. This means that if the API includes structs that have bitfields, if building with gcc, one should use -fnative-struct. For most libraries, this is not a problem. The header files should not include headers found only on mingw. - There should be separate "runtime", "developer", and "source" packages. For small libraries, the first two can well be combined. But please don't force everybody to download and install source files, even if you of course should provide sources in the same location as the binaries. (Yes, I know I have occasionally sinned against this, and only provided links to sources on other sites. I will follow the (L)GPL more closely in the future.) - The developer package should include import libraries both for gcc and MSVC. Or at least the .def file so that the end-developer can generate an import library for the compiler of her choice. Note that if you build with MSVC, the .lib file can be used as such also by gcc. (Perhaps copy foo.lib to libfoo.a just for tradition.) But if you build with gcc, you need Microsoft's lib.exe to build the .lib file. The reason I have until now distributed own versions of libpng, libjpeg and some others is that I, at the time when I needed those, couldn't find suitable binary distributions that would have been good enough from my point of view. But things have improved since then, and I really should go through this stuff and drop my own versions when possible. --tml |
From: Earnie B. <ear...@ya...> - 2002-09-01 00:18:38
|
James Michael DuPont wrote: > I have been complaining about this all the time, I dont want to have to > scrouge the net trying to find all the sources that I need to duplicate > a port. That is why I have been complaining about the section 3 of the > GPL. Yes, this gets broken often. > > That states that all the sources and lib that are not part of the > system have to put placed in the same place as the binaries. A fact easy to miss with only one reading. Everyone needs to read and reread COPYING and COPYING.LIB. > > If people would follow the guidelines layed down by the FSF, > then we would not have these problems. Well, not as many anyway. > > For example, the Dia installer does not have all the sources code of > all the modules with it. > > The pw32 just has binaries, but the source code is missing. > http://sourceforge.net/projects/pw32/ > An all but dead project AFAIK. > > lets look for iconv : > http://sourceforge.net/projects/libiconv/ -- This is from Haible > http://savannah.gnu.org/projects/libiconv -- Oh another one! > http://gettext.sourceforge.net/ -- another port! > http://sourceforge.net/projects/mingwrep/ -- Your Package > http://www.gnu.org/software/libiconv/ -- The GNU Package > http://sourceforge.net/projects/gnuwin32/ -- The One I used > http://www.gimp.org/~tml/gimp/win32/downloads.html -- Contains links to > the gnu package, but not to yours. > http://sourceforge.net/projects/gettext/ -- And the gettext. An impressive list if I may say so. Each one with their own port. I often cringe. > > http://cygwin.com/cgi-bin2/package-cat.cgi?file=libiconv/libiconv-1.8-2-src&grep=iconv > CYGWIN also has a port! Cygwin though isn't native Win32 (i.e.: uses a different runtime other than MSVCRT). Therefore, let's not consider this a Win32 port, it's a Cygwin port. > > In the end, I want to a set of debian source packages that can be > compiled using apt-source/dpkg for windows without any tweaking. I'd be happy for this. > > As I said, I will try out your package, the only reason I posted this > unfinished package was so that someone else can try to compile it. > > I hope that we can consolidate all these versions floating around into > a single and consistent set of packages, you must admit that It is very > confusing!!! > See comments below. > > If the sources had been at the DIA site, then I would have used thiers, > or at the GIMP/GTK port. > > You guys need to fight is out as to WHO is the REAL slim shady! > > Will the real "libiconv" please stand up? Please stand up! > The real libiconv would be the one who owns it, the FSF. One of the problems with these smaller packages is the lack of CVS support. If the official maintainer used CVS then a branch could be set and all of the above porters would have contributed to the same port. > > Then we need to have a link on each of these projects as to who is > doing what. > > Believe me, I dont want to spend any more time than needed on this at > all! > > Maybe a WEBRING would be best, at least you all have each others names, > now please start talking, agree on a standard disclaimer about where to > go to get the newest version, who is doing what. The fight that needs fought is the convincing of each porter to use the subversions CVS. Earnie. |
From: James M. D. <mdu...@ya...> - 2002-09-01 07:21:13
|
--- Earnie Boyd <ear...@ya...> wrote: [SNIP] > > In the end, I want to a set of debian source packages that can be > > compiled using apt-source/dpkg for windows without any tweaking. > > I'd be happy for this. Well It is coming along, the DEBIAN package puts the original sources and a diff file, and the instructions on how to build all in one spot. I hope that I will be producing results soon. But have alot of real world stuff to do like you do as well. > > If the sources had been at the DIA site, then I would have used > thiers, > > or at the GIMP/GTK port. > > > > You guys need to fight is out as to WHO is the REAL slim shady! > > > > Will the real "libiconv" please stand up? Please stand up! > > > > The real libiconv would be the one who owns it, the FSF. One of the > problems with these > smaller packages is the lack of CVS support. If the official > maintainer > used CVS then a > branch could be set and all of the above porters would have > contributed > to the same port. Well, funny enought, I found out that FSF does not own the libiconv, but the gettext. It is quite confusing. Bruno Haible has THREE! different CVS controls of the sources, two on sourceforge (libiconv,clisp), one on savannah. And none on the GNU CVS. > > > > Then we need to have a link on each of these projects as to who is > > doing what. > > > > Believe me, I dont want to spend any more time than needed on this > at > > all! > > > > Maybe a WEBRING would be best, at least you all have each others > names, > > now please start talking, agree on a standard disclaimer about > where to > > go to get the newest version, who is doing what. > > The fight that needs fought is the convincing of each porter to use > the > subversions CVS. Ok, this is where it gets more confusing. Gettext is a GNU package, fsf assigned copyright. But the libintl that contains some of the functions is part of the libc and is not assigned. http://www.gnu.org/directory/Localization/gettext.html Iconv is and is NOT GNU package, but not assigned. http://www.gnu.org/directory/Localization/libiconv.html It is also not in subversions. !!! AND IT IS IN A NEW CVS REPOSITORY !! So it is maintained in THREE DIFFERENT CVSes!! US...@cv...:/cvsroot/clisp http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/clisp/libiconv/?cvsroot=clisp George Greve talke about is here: http://www.gnu.org/brave-gnu-world/issue-30.en.html "The GNU libiconv [13] is the character set conversion library of the GNU Project; through the iconv() function it offers programs the functionality of convert documents between different character sets." I think this is very very very confusing for anyone, no wonder why this is so painful! mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-09-01 13:08:05
|
James Michael DuPont wrote: > > Well, funny enought, I found out that FSF does not own the libiconv, > but the gettext. It is quite confusing. > > Bruno Haible has THREE! different CVS controls of the sources, > two on sourceforge (libiconv,clisp), one on savannah. And none on the > GNU CVS. > Ok, so we have too many CVS versions, hopefully all kept in sync. BTW, there are two for mingw-runtime and w32api. > > > > > > > Then we need to have a link on each of these projects as to who is > > > doing what. > > > > > > Believe me, I dont want to spend any more time than needed on this > > at > > > all! > > > > > > Maybe a WEBRING would be best, at least you all have each others > > names, > > > now please start talking, agree on a standard disclaimer about > > where to > > > go to get the newest version, who is doing what. > > > > The fight that needs fought is the convincing of each porter to use > > the > > subversions CVS. > Ok, this is where it gets more confusing. > > Gettext is a GNU package, fsf assigned copyright. > But the libintl that contains some of the functions is part of the libc > and is not assigned. > http://www.gnu.org/directory/Localization/gettext.html > > Iconv is and is NOT GNU package, but not assigned. > http://www.gnu.org/directory/Localization/libiconv.html > It is also not in subversions. > > !!! AND IT IS IN A NEW CVS REPOSITORY !! > So it is maintained in THREE DIFFERENT CVSes!! > US...@cv...:/cvsroot/clisp > http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/clisp/libiconv/?cvsroot=clisp > > George Greve talke about is here: > http://www.gnu.org/brave-gnu-world/issue-30.en.html > "The GNU libiconv [13] is the character set conversion library of the > GNU Project; through the iconv() function it offers programs the > functionality of convert documents between different character sets." > > I think this is very very very confusing for anyone, > no wonder why this is so painful! > Yea, me too. I'll respond to this more later. Earnie. |
From: Bruno H. <br...@cl...> - 2002-09-02 15:01:00
|
James Michael DuPont writes: > First of all I am talking about a mingw32 under debian, and second of > all, please excuse that I overlooked your particular port, because > there is no clear guidelines for the user as to which of the MANY ports > he should use. * If you want to build from source, start out at the package's homepage, as listed on freshmeat.net. * If you want cygwin binaries, go to http://www.cygwin.com/ and http://www.cygwin.com/download.html * If you want mingw32 binaries, go to http://mingwrep.sourceforge.net/ * If you want pw32 binaries, go to http://pw32.sourceforge.net/ I think the confusion would be less if the http://gnuwin32.sourceforge.net/ page would state clearly which environment/compiler they use: mingw32 or pw32 or cygwin or msvc. Your platform ("mingw32 under debian") appears to be new. With each new platform or set of packaging rules you start from scratch. > lets look for iconv : > http://sourceforge.net/projects/libiconv/ -- This is from Haible This is the CVS repository for libiconv. > http://savannah.gnu.org/projects/libiconv -- Oh another one! This is the CVS repository for libiconv's homepage. > http://www.gnu.org/software/libiconv/ -- The GNU Package This is libiconv's homepage. Earnie Boyd writes: > The real libiconv would be the one who owns it, the FSF. One of the > problems with these smaller packages is the lack of CVS support. If > the official maintainer used CVS then a branch could be set and all > of the above porters would have contributed to the same port. All wrong. libiconv is maintained in a CVS, and the lack of CVS branches for cygwin/mingw32/etc. is because: - It compiles out of the box on cygwin, - It compiles out of the box for mingw32, except for a one-liner patch, - It compiles out of the box for msvc, using the included Makefile.msvc. James Michael DuPont writes: > I found out that FSF does not own the libiconv Wrong. The FSF does own libiconv. Look at the copyright notices. > Bruno Haible has THREE! different CVS controls of the sources, > two on sourceforge (libiconv,clisp), one on savannah. And none on the > GNU CVS. Wrong again. Take a look at the contents of these CVS repositories. Only one of them contains the maintained sources of libiconv. Bruno |
From: James M. D. <mdu...@ya...> - 2002-09-02 15:56:28
|
Bruno, Thank you for pointing out my mistakes, you have shed some light on this whole issue. I hope that my asking questions have helped in some way to bring all these questions to light, even if I was wrong on my conclusions. --- Bruno Haible <br...@cl...> wrote: > James Michael DuPont writes: > > > First of all I am talking about a mingw32 under debian, and second > of > > all, please excuse that I overlooked your particular port, because > > there is no clear guidelines for the user as to which of the MANY > ports > > he should use. > > * If you want to build from source, start out at the package's > homepage, as listed on freshmeat.net. > > * If you want cygwin binaries, go to http://www.cygwin.com/ and > http://www.cygwin.com/download.html > > * If you want mingw32 binaries, go to > http://mingwrep.sourceforge.net/ And this is the official port? So http://gnuwin32.sourceforge.net/ and it are in competition? > * If you want pw32 binaries, go to http://pw32.sourceforge.net/ Do you know where to find libiconv there? > I think the confusion would be less if the > http://gnuwin32.sourceforge.net/ page would state clearly which > environment/compiler they use: mingw32 or pw32 or cygwin or msvc. Well, you do have to click a few times to find it, http://gnuwin32.sourceforge.net/compile.html tells you that mingw is needed. > Your platform ("mingw32 under debian") appears to be new. With each > new platform or set of packaging rules you start from scratch. I will do just that. The only things that were a problem were some linking problems, I will be posting very detailed patches to you on anything I find. > > lets look for iconv : > > http://sourceforge.net/projects/libiconv/ -- This is from Haible > > This is the CVS repository for libiconv. That is what I will be using. > > http://savannah.gnu.org/projects/libiconv -- Oh another one! > > This is the CVS repository for libiconv's homepage. Ahhh.... I was to quick to shoot! Sorry. :) > > > http://www.gnu.org/software/libiconv/ -- The GNU Package > > This is libiconv's homepage. OK, well it looks like every other page (including the gnu software directory) is slightly off. > > Earnie Boyd writes: > > The real libiconv would be the one who owns it, the FSF. One of > the > > problems with these smaller packages is the lack of CVS support. > If > > the official maintainer used CVS then a branch could be set and all > > of the above porters would have contributed to the same port. > > All wrong. libiconv is maintained in a CVS, and the lack of CVS > branches for cygwin/mingw32/etc. is because: > > - It compiles out of the box on cygwin, > - It compiles out of the box for mingw32, except for a one-liner > patch, > - It compiles out of the box for msvc, using the included > Makefile.msvc. This is fine, I noticed that you just updated cvs with the mingw32 stuff. I will be using your cvs for compilation and writing to all the people who distribute binaries to update thier links to point at your page. You must admit however, that for a complete outsider, it is very confusing! > James Michael DuPont writes: > > I found out that FSF does not own the libiconv > > Wrong. The FSF does own libiconv. Look at the copyright notices. I am sorry about this misunderstanding, I was not looking deep enought, trying to go on superficial information. Even in my discussion with the FSF, they did not know offhand that libiconv was thier own copyright. "Copyright (C) 1999-2001 Free Software Foundation, Inc. This file is part of the GNU LIBICONV Library." But on the webpage here : http://www.gnu.org/directory/libiconv.html It states : "This is not a GNU package." (Note that it (Broken) links to here which is not here: ftp://ftp.ilog.fr/pub/Users/haible/gnu/libiconv-1.8.tar.gz > > > Bruno Haible has THREE! different CVS controls of the sources, > > two on sourceforge (libiconv,clisp), one on savannah. And none on > the > > GNU CVS. > > Wrong again. Take a look at the contents of these CVS repositories. > Only one of them contains the maintained sources of libiconv. OK, it is this one : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libiconv/libiconv/ Thanks again for you time, you have cleared up many of my questions. mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Bruno H. <br...@cl...> - 2002-09-02 16:32:27
|
James Michael DuPont writes: > > I think the confusion would be less if the > > http://gnuwin32.sourceforge.net/ page would state clearly which > > environment/compiler they use: mingw32 or pw32 or cygwin or msvc. > Well, you do have to click a few times to find it, > http://gnuwin32.sourceforge.net/compile.html tells you that mingw is > needed. Then there is competition between between this site and http://mingwrep.sourceforge.net/, and it would be best if these two projects described how they differ, and whether packages from one site are interoperable with packages from the other site. > > * If you want pw32 binaries, go to http://pw32.sourceforge.net/ > Do you know where to find libiconv there? No I'm not aware of a port of libiconv to pw32. > The only things that were a problem were some > linking problems, Strange. With the mingw-2.1 (which I got from http://www.cygwin.com/mirrors.html, *not* from http://www.mingw.org/) libiconv builds out of the box. > But on the webpage here : > http://www.gnu.org/directory/libiconv.html > It states : "This is not a GNU package." > > (Note that it (Broken) links to here which is not here: > ftp://ftp.ilog.fr/pub/Users/haible/gnu/libiconv-1.8.tar.gz Thanks for reporting this; will be fixed. Bruno |
From: Kees Z. <kz...@us...> - 2002-09-02 20:15:29
|
----- Oorspronkelijk bericht ----- Van: "Bruno Haible" <br...@cl...> Aan: "James Michael DuPont" <mdu...@ya...> CC: "stefan" <st...@lk...>; <gnu...@li...>; <ko...@us...>; <dia...@gn...>; <gim...@ya...>; <Min...@li...> Verzonden: maandag 2 september 2002 18:33 Onderwerp: [Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring) > James Michael DuPont writes: > > > I think the confusion would be less if the > > > http://gnuwin32.sourceforge.net/ page would state clearly which > > > environment/compiler they use: mingw32 or pw32 or cygwin or msvc. > > Well, you do have to click a few times to find it, > > http://gnuwin32.sourceforge.net/compile.html tells you that mingw is > > needed. > > Then there is competition between between this site and > http://mingwrep.sourceforge.net/, and it would be best if these two > projects described how they differ, and whether packages from one site > are interoperable with packages from the other site. > The differences between Mingwrep and Gnuwin32 are, as far as I can see: - Gnuwin32 always provides the source (which usually is required by the license of the original package) with any changes from the original source in the form of a diff. - Gnuwin32 always provides the documentation in a 'compiled' form, i.e. as PDF, HTML, PS, DVI and HLP. - Gnuwin32 provides import libraries for MSVC and BCC wherever possible. In general static and import libraries from Gnuwin32 should be interoperable with libraries from Mingwrep, although the options with which the library files have been compiled might differ (in particular, most libraries, and binaries, from Gnuwin32 have been compiled without debug option). Kees Zeelenberg |
From: James M. D. <mdu...@ya...> - 2002-09-03 06:55:29
|
--- Bruno Haible <br...@cl...> wrote: > > The only things that were a problem were some > > linking problems, > > Strange. With the mingw-2.1 (which I got from > http://www.cygwin.com/mirrors.html, > *not* from http://www.mingw.org/) > libiconv builds out of the box. > I am working under DEBIAN linux using a cross compiler, on creating a package that can be built from apt-get source/apt-src --build install. The changes that I needed to make were relevant to the linker and compiler settings, and specific to the the cross compiler. If the user has WINE installed, he can even execute the tests from config to get the needed values, this is another part that needs changing. If I find some more time this week, I will post a very detailed report on exactly what changes need to be made to compile under DEBIAn/mingw32 Mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-09-02 19:10:28
|
Bruno Haible wrote: > Strange. With the mingw-2.1 (which I got from > http://www.cygwin.com/mirrors.html, > *not* from http://www.mingw.org/) > libiconv builds out of the box. > Same package loaded by the same maintainer to two different distribution site. The difference, and this in itself should cause no difference, I choose to build the Cygwin release with Cygwin's gcc and the MinGW release with the MinGW gcc. Earnie. |
From: Earnie B. <ear...@ya...> - 2002-09-01 00:18:42
|
stefan wrote: > On Fri, 30 Aug 2002, James Michael DuPont wrote: > > > Dear fellow hackers, > > Hello! > > > I am working on putting my packages on sourceforge right now, > > https://sourceforge.net/project/showfiles.php?group_id=19878 > > I still have not converted all of my packages to the high standards > > that I preach, this of course makes me a hypocrite in one aspect. > > The 'libiconv' library "port" for MinGW32 has always been maintained at > the 'mingwrep' project on sourceforge. > > <http://sourceforge.net/project/showfiles.php?group_id=7382> > > Too bad we are doing duplicate work... > I've never liked this project. Why have a different site from the official MinGW site. Earnie. |