From: Thomas S. <tks...@gm...> - 2010-09-20 01:19:26
|
Hi On brand new MingW (installed by mingw-get): 'mingw-get install zlib' installs the doc, man and lic components only. But what I want of course is the header and libraries. What gives? -- Tom |
From: LRN <lr...@gm...> - 2010-09-20 01:58:09
|
On 20.09.2010 5:19, Thomas Sharpless wrote: > Hi > > On brand new MingW (installed by mingw-get): 'mingw-get install zlib' > installs the doc, man and lic components only. > > But what I want of course is the header and libraries. What gives? > > -- Tom Speaking of zlib, i should remind package maintainers that zlib package requires an update, because libz.dll.a lacks gzdirect. |
From: LRN <lr...@gm...> - 2010-09-20 15:45:13
|
On 20.09.2010 5:57, LRN wrote: > On 20.09.2010 5:19, Thomas Sharpless wrote: >> Hi >> >> On brand new MingW (installed by mingw-get): 'mingw-get install zlib' >> installs the doc, man and lic components only. >> >> But what I want of course is the header and libraries. What gives? >> >> -- Tom > Speaking of zlib, i should remind package maintainers that zlib > package requires an update, because libz.dll.a lacks gzdirect. Speaking of updating zlib package, here are mingw32-build.sh and mingw32-patch.01 that should be suitable for building zlib-1.2.5 package, and release notes (since mingw32-build.sh won't generate them) |
From: Keith M. <kei...@us...> - 2011-04-09 17:16:07
|
On 09/04/11 16:49, LRN wrote: > Speaking AGAIN of updating zlib package... You may speak about it until you are blue in the face--the simple fact is that we don't have a maintainer for a mingw32-zlib package, (and IIRC, you declined a previous invitation to become formally associated with the project in any such capacity). The ONLY reason we have a zlib-1.2.3-mingw32 package at all is because that's what I'm using for mingw-get, and I have to distribute it to fulfil my GPL obligations. I simply don't have the time or the energy to keep chasing updates to newer upstream releases, especially given their flawed build system; in common with all projects which mistakenly believe that their needs are too modest to warrant using autoconf, they are doomed to repeat in perpetuity, the mistakes that autoconf learned to avoid years ago--if it doesn't cross-compile OOTB, it's broken, (not to mention that it probably took significantly longer to write their current bespoke configure script, than it would have taken to construct a much more robust configure.ac from the outset). -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2011-04-09 18:45:05
|
On 4/9/2011 1:15 PM, Keith Marshall wrote: > On 09/04/11 16:49, LRN wrote: >> Speaking AGAIN of updating zlib package... > > You may speak about it until you are blue in the face--the simple fact > is that we don't have a maintainer for a mingw32-zlib package, Oh? Keith, I was under the impression that you were taking ownership of mingw-zlib and mingw-bzip2, precisely BECAUSE > that's what I'm using for mingw-get However, if you're not willing to continue maintaining the packages, I can pick them up, N.P. I was only ignoring messages re: mingw-zlib and mingw-bzip because I didn't want to step on your toes. , and I have to distribute it to > fulfil my GPL obligations. I simply don't have the time or the energy > to keep chasing updates to newer upstream releases, especially given > their flawed build system; No kidding. It's ridiculous. But...I have to deal with it for cygwin's cygwin-zlib/bzip2 AND cygwin's pseudo-cross-compile cygwin-mingw-zlib/bzip2 packages (those are used for *cygwin's* setup.exe) It's not much more effort for me to handle msys-zlib/bzip2 + mingw-zlib/bzip2 as well. > in common with all projects which mistakenly > believe that their needs are too modest to warrant using autoconf, they > are doomed to repeat in perpetuity, the mistakes that autoconf learned > to avoid years ago--if it doesn't cross-compile OOTB, it's broken, (not > to mention that it probably took significantly longer to write their > current bespoke configure script, than it would have taken to construct > a much more robust configure.ac from the outset). Even jpeg eventually saw the light, but I fear zlib is a hopeless case. :-P LRN, give me a few days and I'll update mingw-zlib... -- Chuck |
From: LRN <lr...@gm...> - 2011-04-09 18:12:53
|
On 09.04.2011 21:15, Keith Marshall wrote: > On 09/04/11 16:49, LRN wrote: >> Speaking AGAIN of updating zlib package... > You may speak about it until you are blue in the face--the simple fact > is that we don't have a maintainer for a mingw32-zlib package, (and > IIRC, you declined a previous invitation to become formally associated > with the project in any such capacity). I have declined a formal status, but i, evidently, didn't refuse to do things. I do what i can/want, when/if i can/want. Which isn't, honestly, any different from what formal MinGW Project members do. > The ONLY reason we have a zlib-1.2.3-mingw32 package at all is because > that's what I'm using for mingw-get, and I have to distribute it to > fulfil my GPL obligations. I simply don't have the time or the energy > to keep chasing updates to newer upstream releases, That's unfortunate, because zlib is a prerequisite for more than nine thousands pieces of software. And half of them wants something newer than 1.2.3, but are stuck with 1.2.3 in /mingw. It is possible, obviously, to just install a self-built 1.2.5 on top of 1.2.3, but that means sidestepping mingw-get, and that is never a good thing. > especially given > their flawed build system; Considering the fact that zlib is relatively small, it might be possible to just write an autotools-based buildsystem for it. And submit it upstream. I mean, they have 5 (five) special makefiles for non-*nix platforms. Extra configure.ac won't hurt ;). They could take a stubborn stance, of course, and refuse it, in which case it will have to be maintained separately (yes, i know that you hate maintenance). Speaking of which. If you can't update the package on mingw.org, maybe it's possible to host it somewhere else (in another repository). I've been able to use more than one repository, but the other repository in that case had a different subsystem prefix. Using two or more repositories with the same subsystem prefix is terra incognita for me at the moment. Though i do think that <repository uri="http://prdownloads.sourceforge.net/mingw/%F.xml.lzma?download"> <package-list catalogue="package-list" /> </repository> <repository uri="http://blah-blah-blah/%F.xml.lzma"> <package-list catalogue="package-list" /> </repository> should work reasonably well (unless mingw-get uses package list names as identifiers for...well...package lists...or maybe it doesn't matter how package lists are named?). What i do not know is how mingw-get would react when it finds mingw32-zlib in BOTH repositories (or in more than one package list in the same repository). Also, what would happen if one repository contains newer version than the other one? Would mingw-get install the first one it finds? Or the newest one? Does the order in which repositories are listed matters? Can mingw-get be forced to use a particular repo from the commandline? Can mingw-get be forced to install a particular version of the package (mingw-get install mingw-gcc-4.6.0?)? |
From: Charles W. <cwi...@us...> - 2011-04-09 18:51:45
|
On 4/9/2011 2:12 PM, LRN wrote: > On 09.04.2011 21:15, Keith Marshall wrote: >> The ONLY reason we have a zlib-1.2.3-mingw32 package at all is because >> that's what I'm using for mingw-get, and I have to distribute it to >> fulfil my GPL obligations. I simply don't have the time or the energy >> to keep chasing updates to newer upstream releases, > That's unfortunate, because zlib is a prerequisite for more than nine > thousands pieces of software. And half of them wants something newer > than 1.2.3, And /this/ is a failure of the zlib people. They changed their ABI (API?) between two micro releases. @#$!!@#%!@#% > but are stuck with 1.2.3 in /mingw. It is possible, > obviously, to just install a self-built 1.2.5 on top of 1.2.3, but that > means sidestepping mingw-get, and that is never a good thing. Ack. >> especially given >> their flawed build system; > Considering the fact that zlib is relatively small, it might be possible > to just write an autotools-based buildsystem for it. And submit it > upstream. It's been tried before. They are not interested. Something about zlib being more portable than m4/sh/perl/whathaveyou -- as if embedded systems are developed "natively" instead of on a cross-compiler build system with full m4/sh/perl support. Be that as it may -- that's the situation we're in. Zlib won't be going autoconf in my lifetime. > I mean, they have 5 (five) special makefiles for non-*nix > platforms. Extra configure.ac won't hurt ;). They could take a stubborn > stance, of course, and refuse it, in which case it will have to be > maintained separately (yes, i know that you hate maintenance). It's just easier -- less maintenance -- to hack up their hodgepodge and use it directly, rather than tracking all their individual #define this for subfeature X, #define that for subfeature y, handrolled crap. Which seems to proliferate with each micro release. Now, they're adding hand-coded assembly for about 50 different embedded processors... > Speaking of which. If you can't update the package on mingw.org, maybe > it's possible to host it somewhere else (i Not necessary; we've just had a misunderstanding among the mingw devs themselves. All sorted now. Stay tuned for a zlib update. > What i do not know is how mingw-get would react when it finds > mingw32-zlib in BOTH repositories I think the one listing a newer version wins, always, unless you explicitly specify a particular (older) version to install or "upgrade" to. -- Chuck |
From: LRN <lr...@gm...> - 2011-04-09 15:50:02
Attachments:
zlib-1.2.5-0RC1-mingw32-build.tar.xz
|
On 20.09.2010 19:45, LRN wrote: > On 20.09.2010 5:57, LRN wrote: >> On 20.09.2010 5:19, Thomas Sharpless wrote: >>> Hi >>> >>> On brand new MingW (installed by mingw-get): 'mingw-get install zlib' >>> installs the doc, man and lic components only. >>> >>> But what I want of course is the header and libraries. What gives? >>> >>> -- Tom >> Speaking of zlib, i should remind package maintainers that zlib >> package requires an update, because libz.dll.a lacks gzdirect. > Speaking of updating zlib package, here are mingw32-build.sh and > mingw32-patch.01 that should be suitable for building zlib-1.2.5 > package, and release notes (since mingw32-build.sh won't generate them) Speaking AGAIN of updating zlib package, here is the buildscript for 1.2.5. A bit more civilized than mingw32-build.sh . Not sure about using it for cross-compiling (release notes for 1.2.3 claim that it was cross-compiled). OTOH it can be used to build msys version of zlib (replace subsys=mingw32 with subsys=msys; didn't have a chance to test that). |
From: Charles W. <cwi...@us...> - 2010-09-20 03:18:22
|
On 9/19/2010 9:19 PM, Thomas Sharpless wrote: > On brand new MingW (installed by mingw-get): 'mingw-get install zlib' > installs the doc, man and lic components only. > > But what I want of course is the header and libraries. What gives? Well, there are two different zlibish packages. There's the one for *msys* applications: msys-zlib-dll msys-zlib-dev msys-zlib-doc msys-zlib-lic Then, there's the mingw one: mingw32-zlib-doc aka zlib-doc mingw32-zlib-lic aka zlib-lic mingw32-zlib-man aka zlib-man mingw32-libz-dll aka libz-dll mingw32-libz-dev aka libz-dev If you install "zlib" then you get all three of the mingw32 packages whose aliases begin with "zlib". You also probably get libz-dll by default, simply because several other packages depend on it. What you DON'T get is libz-dev. You have to install that manually. We really need a 'mingw-get show' command, but nobody has had enough 'tuits to get around ...tuit. -- Chuck |
From: Thomas S. <tks...@gm...> - 2010-09-20 13:01:21
|
Thanks, Chuck On Sun, Sep 19, 2010 at 11:16 PM, Charles Wilson < cwi...@us...> wrote: > > Well, there are two different zlibish packages. There's the one for > *msys* applications: > > msys-zlib-dll > msys-zlib-dev > msys-zlib-doc > msys-zlib-lic > > Then, there's the mingw one: > > mingw32-zlib-doc aka zlib-doc > mingw32-zlib-lic aka zlib-lic > mingw32-zlib-man aka zlib-man > mingw32-libz-dll aka libz-dll > mingw32-libz-dev aka libz-dev > > If you install "zlib" then you get all three of the mingw32 packages > whose aliases begin with "zlib". You also probably get libz-dll by > default, simply because several other packages depend on it. > I don't think I got libz-dll. Didn't see it int the command output. > > What you DON'T get is libz-dev. You have to install that manually. > > Done; thanks. > We really need a 'mingw-get show' command, but nobody has had enough > 'tuits to get around ...tuit. > Even a page on the website that lists all the usable prefixes and full names would help a lot. I tried to guess but didn't think of 'libz-dev'. -- Tom > -- > Chuck > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Thomas S. <tks...@gm...> - 2010-09-20 13:05:11
|
PS 'mingw32-libz-dev.xml' is not on the package list spit out by mingw-get. Is that name hidden inside the zlib.xml package? -- Tom On Mon, Sep 20, 2010 at 9:01 AM, Thomas Sharpless <tks...@gm...>wrote: > Thanks, Chuck > > On Sun, Sep 19, 2010 at 11:16 PM, Charles Wilson < > cwi...@us...> wrote: > >> >> Well, there are two different zlibish packages. There's the one for >> *msys* applications: >> >> msys-zlib-dll >> msys-zlib-dev >> msys-zlib-doc >> msys-zlib-lic >> >> Then, there's the mingw one: >> >> mingw32-zlib-doc aka zlib-doc >> mingw32-zlib-lic aka zlib-lic >> mingw32-zlib-man aka zlib-man >> mingw32-libz-dll aka libz-dll >> mingw32-libz-dev aka libz-dev >> >> If you install "zlib" then you get all three of the mingw32 packages >> whose aliases begin with "zlib". You also probably get libz-dll by >> default, simply because several other packages depend on it. >> > > I don't think I got libz-dll. Didn't see it int the command output. > >> >> What you DON'T get is libz-dev. You have to install that manually. >> >> Done; thanks. > > >> We really need a 'mingw-get show' command, but nobody has had enough >> 'tuits to get around ...tuit. >> > > Even a page on the website that lists all the usable prefixes and full > names would help a lot. I tried to guess but didn't think of 'libz-dev'. > > -- Tom > > >> -- >> Chuck >> >> >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> MinGW-users mailing list >> Min...@li... >> >> This list observes the Etiquette found at >> http://www.mingw.org/Mailing_Lists. >> We ask that you be polite and do the same. Disregard for the list >> etiquette may cause your account to be moderated. >> >> _______________________________________________ >> You may change your MinGW Account Options or unsubscribe at: >> https://lists.sourceforge.net/lists/listinfo/mingw-users >> > > |