Re: Guile-1.5.6-4 available for review/upload
> "janneke" == janneke <[EMAIL PROTECTED]> writes: janneke> MIME-Version: 1.0 janneke> Content-Type: text/plain; charset=us-ascii janneke> This release brings a number of bugfixes for the hint files, and also janneke> guile-readline support. Most of this thanks to Charles Wilson. janneke> It's my first release built using mknetrel. janneke> Please upload [if you don't spot some stupid mistake]. There is a packaging bug in guile-1.5.6-4.tar.gz The directory name is just: usr/doc/-1.5.6-4 it's missing guile ... janneke> Greetings, janneke> Jan. Ciao Volker
Re: libtoolize and glib-1.2.10
Lapo Luchini wrote: >> B)He could try adding AC_LIBTOOL_WIN32_DLL right before >> AM_PROG_LIBTOOL in configure.in, which should tell configure that >> building dlls is "OK". However, I will note that the end result is >> "undefined symbol Win@Main16" %50 of the time. > > > Nope, it still says the package doesn't support them... > >> C)Can you help him by referring him to the best documentation for the >> whole process? I would try, but I learned mostly from trial and >> error. (A howto for cygwin really should be written...). > > > Can you nonetheless give me some links? > I'm doing some google on the words "automake", "autotool", but found > nothing really enlightening > >> D)As I have told you on countless occasions, I use autoupdate to get >> me started. I then 'diff -u configure.in~ configure.in' to see what >> it changed. After evaluating what it changed, I will then go in and >> hand edit/revert anything else. This method works quite well in >> that autoupdate 99% of the time does all the busywork for me, >> leaving it to me to fix up any special cases or macros. > > > OK. I can see what is changed... but I don't understamd what it means ^_^ > I guess I'll pay "info automake" a major visit... it will take some > time, though. > > BTW: using autoupdate/libtoolize/automake/autoheader/autoconf I end up > having lotsa warnings > http://sources.redhat.com/autobook/ is a good place to get started, be sure to do the exercises included. Then read the following: http://www.gnu.org/manual/autoconf-2.53/html_node/index.html http://www.gnu.org/manual/automake-1.6.1/html_node/automake_toc.html http://www.gnu.org/manual/libtool-1.4.2/html_node/libtool_toc.html http://www.murrayc.com/learning/linux/automake/automake.shtml After that, brush up on what's changed by checking out the info pages for the various utilities, since libtool is a CVS version and automake is v1.6.2. Then check out Chuck's dllhelpers, which contain exercises for people to get used to using the autotools on Cygwin: http://www.neuro.gatech.edu/users/cwilson/cygutils/dll-stuff/index.html This should take about 1-2 weeks to learn, I'd estimate. You'll be glad you did, since about 85% of the packages out there use some form of the autotools. If you run into problems, your best resource is the Autoconf/Automake/Libtool mailing lists. Just send a question there with the output, and they should be able to help. Cheers, Nicholas
Re: non-stripped cygcurl-2.dll available - could someone upload please?
On Wed, Jul 17, 2002 at 11:27:22AM -0400, Roth, Kevin P. wrote: > Per the discussion in the thread "rebase problem for cygcurl-2.dll still >existing?!", I have re-built the curl package with the shared library DLL >(cygcurl-2.dll) no longer being stripped. > > Could someone please upload it for me? > > It's downloadable from: > http://curl.haxx.se/download/curl-7.9.8-2-cygwin.tar.bz2 > with source being at: > http://curl.haxx.se/download/curl-7.9.8-2-src-cygwin.tar.bz2 > > As always, please remove "-cygwin" from the file names and then upload as usual. Uploaded. Could you please create a subdirectory next time instead of using the "-cygwin" in the name? Thakns, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: libtoolize and glib-1.2.10
> B)He could try adding AC_LIBTOOL_WIN32_DLL right before > AM_PROG_LIBTOOL in configure.in, which should tell configure that > building dlls is "OK". However, I will note that the end result is > "undefined symbol Win@Main16" %50 of the time. Nope, it still says the package doesn't support them... > C)Can you help him by referring him to the best documentation for the > whole process? I would try, but I learned mostly from trial and > error. (A howto for cygwin really should be written...). Can you nonetheless give me some links? I'm doing some google on the words "automake", "autotool", but found nothing really enlightening > D)As I have told you on countless occasions, I use autoupdate to get > me started. I then 'diff -u configure.in~ configure.in' to see what > it changed. After evaluating what it changed, I will then go in and > hand edit/revert anything else. This method works quite well in that > autoupdate 99% of the time does all the busywork for me, leaving it > to me to fix up any special cases or macros. OK. I can see what is changed... but I don't understamd what it means ^_^ I guess I'll pay "info automake" a major visit... it will take some time, though. BTW: using autoupdate/libtoolize/automake/autoheader/autoconf I end up having lotsa warnings -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP & X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
RE: rebase problem for cygcurl-2.dll still existing?!
I've got my non-stripped package coming. The non-stripped DLL is about 350 kb larger, although after bzipping, it's only about 80 kb of additional network download (total of 546 kb in the .tar.bz2 file now). Many thanks to those of you (Jason, Robert) who helped explain rebase to those of us who weren't in the know. I have two additional questions: 1) strip.exe offers a "--strip-unneeded" option, which claims to strip all symbols "not needed for relocation". That sounds like what I want (strip some debugging symbols, but leave enough for rebase-ing to succeed?). However, after I tried that option, rebase-ing failed (with the ReBaseImage() error). Does this indicate a problem with rebase.exe (v1.18), or is this the wrong interpretation of "--strip-unneeded"? Is there any other method available to do a "partial" strip? 2) I could split off the development-oriented pieces of the curl package into a separate "curl-devel" package, which would save on disk space for non-developers. Should I take this step when the next version comes along? Thanks, --Kevin
non-stripped cygcurl-2.dll available - could someone upload please?
Per the discussion in the thread "rebase problem for cygcurl-2.dll still existing?!", I have re-built the curl package with the shared library DLL (cygcurl-2.dll) no longer being stripped. Could someone please upload it for me? It's downloadable from: http://curl.haxx.se/download/curl-7.9.8-2-cygwin.tar.bz2 with source being at: http://curl.haxx.se/download/curl-7.9.8-2-src-cygwin.tar.bz2 As always, please remove "-cygwin" from the file names and then upload as usual. Thanks, --Kevin
Building setup.exe w/ the latest revision of gcc-3.1.1
Hi, According to Chris' announcement for the latest test version of gcc, he said that he was able to partially compile setup.exe with only a minor problem b/c of some patches. Out of curiosity, has anyone else experienced success with the new round of compilers? I'm currently trying a few different combinations regarding CPPFLAGS/gcc version and such, but so far I've had no success. So, I thought I'd ask and see if anyone else has had success, and if so what flags were they using? Back on July 11, Pavel mentioned a few work arounds, but those seem not to be necessary(?) anymore. Cheers, Nicholas
RE: setup.exe and replacing of in-use files
> > On Mon, Jul 15, 2002 at 02:07:44PM +0200, Ralf Habacker wrote: > > > using release number like 2.2.2-[ab][0-9] has historical reasons and > > > because of the problems of the sourceforge file release system as I > > > wrote in http://www.cygwin.com/ml/cygwin-apps/2002-07/msg00440.html I > > > can't change this for already released files :-(, > > > > > > so are there any other possibilities to solve this problem ? > > > > PRC-Tools tells its users to point setup.exe at > > > > http://prc-tools.sourceforge.net/install/ > > > > (i.e. our Sourceforge *website*) and then uses HTTP redirects therein to > > map whatever collective hallucination we'd like setup.exe to see into > > the reality of the Sourceforge file release system. For us, it's pretty > > simple: > > > > .../htdocs/install/.htaccess: > > RedirectMatch install/(.*[^/].*/.*) > http://us.dl.sourceforge.net/sourceforge/$1 > > > thanks for this hint, it works for me too. > > Please grant me one question with this redirect. Perhaps you can help me: > > This redirect requires a path like "/file" in the setup.ini. > I've tried to change the above line into > > RedirectMatch install/(.*)$ > http://us.dl.sourceforge.net/sourceforge//$1 > > to avoid this preeceding but this doesn't work and > the apache > online help of mod_alias doesn't gave me enough infos to find the problem. Any > ideas ? > John, forgot this additional request, it works. It seems to me that the internet explorers cache handling has made some problems. Again thanks for your help > Ralf > > > >
RE: setup.exe and replacing of in-use files
> On Mon, Jul 15, 2002 at 02:07:44PM +0200, Ralf Habacker wrote: > > using release number like 2.2.2-[ab][0-9] has historical reasons and > > because of the problems of the sourceforge file release system as I > > wrote in http://www.cygwin.com/ml/cygwin-apps/2002-07/msg00440.html I > > can't change this for already released files :-(, > > > > so are there any other possibilities to solve this problem ? > > PRC-Tools tells its users to point setup.exe at > > http://prc-tools.sourceforge.net/install/ > > (i.e. our Sourceforge *website*) and then uses HTTP redirects therein to > map whatever collective hallucination we'd like setup.exe to see into > the reality of the Sourceforge file release system. For us, it's pretty > simple: > > .../htdocs/install/.htaccess: > RedirectMatch install/(.*[^/].*/.*) http://us.dl.sourceforge.net/sourceforge/$1 > thanks for this hint, it works for me too. Please grant me one question with this redirect. Perhaps you can help me: This redirect requires a path like "/file" in the setup.ini. I've tried to change the above line into RedirectMatch install/(.*)$ http://us.dl.sourceforge.net/sourceforge//$1 to avoid this preeceding but this doesn't work and the apache online help of mod_alias doesn't gave me enough infos to find the problem. Any ideas ? Ralf
Re: [ITP] libungif-4.1.0-2
On Wed, Jul 17, 2002 at 02:51:58PM +0200, Lapo Luchini wrote: > I would upload this as is. Done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ITP] libungif-4.1.0-2
Corinna Vinschen wrote: >On Tue, Jul 16, 2002 at 05:44:33PM +0200, Lapo Luchini wrote: > > >>>Yes, sometimes I do this; I have a "prep" and a "prep2" stage -- not a >>>very creative or informative naming scheme, I'll admit. >>>Yes, I think -3 is ready to upload; there's no need to futz with it >>>any more. Just let 'er rip. >>> >>> >>As I sais earlier I didn't change the release for this very small >>change, the url with the new files is still >>http://www.lapo.it/tmp/libungif-4.1.0-2.tar.bz2 >>http://www.lapo.it/tmp/libungif-4.1.0-2-src.tar.bz2 >> >> >So, shall I upload it now? > > Well I don't think the main problem (using the small patch method is difficult to patch it further) does apply there, as the program will rarely get updated by his authors, if ever. Even if patches were needed, I still think that complicating the script to support something like "prep"/"prep2" would be way better that hiding 1k of "real" patches into 500k of "automatic" patches. People would have an hard time knowing what actually needs to be patched and what is automatically done relibtoolizing. I would upload this as is. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP & X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
Re: [ITP] libungif-4.1.0-2
Corinna Vinschen wrote: >On Tue, Jul 16, 2002 at 05:44:33PM +0200, Lapo Luchini wrote: > >>>Yes, sometimes I do this; I have a "prep" and a "prep2" stage -- not a >>>very creative or informative naming scheme, I'll admit. >>>Yes, I think -3 is ready to upload; there's no need to futz with it >>>any more. Just let 'er rip. >>> >>As I sais earlier I didn't change the release for this very small >>change, the url with the new files is still >>http://www.lapo.it/tmp/libungif-4.1.0-2.tar.bz2 >>http://www.lapo.it/tmp/libungif-4.1.0-2-src.tar.bz2 >> > >So, shall I upload it now? > I'll give it my vote, it installs cleanly here. Since Chuck has left :-[, I guess there isn't really any further discussion to be had. Cheers, Nicholas
Re: rebase problem for cygcurl-2.dll still existing?!
Robert Collins wrote: > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms >>Sent: Wednesday, 17 July 2002 10:09 PM >>To: Jason Tishler >>Cc: [EMAIL PROTECTED] >>Subject: Re: rebase problem for cygcurl-2.dll still existing?! >> >> >>Jason Tishler wrote: >> >> Is that a deficiency of cygwin as a whole, or just related >>to the way >> my DLL was built?) >>>Cygwin's fork() attempts to load DLLs in the child in the >>> >>same location >> >>>as in the parent. If it fails, then the child aborts. >>> >>> >>Other than the lack of someone writing the code, is there any >>reason why >>fork() can't automagically try another location? Is this >>even possible? >> Or does it go against the way Cygwin/Windows works? >> > >It goes against the way fork works. > >Take a pointer foo with value bar. After fork, *foo must equal *foo >before the fork. If bar points into a dll, and the dll is mapped >somewhere else, then after fork *foo != *foo before the fork. > Thank you, Rob. That clears things up for me. :-) Cheers, Nicholas
Re: rebase problem for cygcurl-2.dll still existing?!
Earnie Boyd wrote: >Nicholas Wourms wrote: > >>Jason Tishler wrote: >> >> Is that a deficiency of cygwin as a whole, or just related to the way my DLL was built?) >>>Cygwin's fork() attempts to load DLLs in the child in the same location >>>as in the parent. If it fails, then the child aborts. >>> >>> >>Other than the lack of someone writing the code, is there any reason why >>fork() can't automagically try another location? Is this even possible? >> Or does it go against the way Cygwin/Windows works? >> >> > >The correct answer to this question is "Use the source, Luke" (tm). > I would except that process handling and memory management are not in my areas of expertise. My intent was only for a brief elaboration on the previous comment and an inquiry as to why it isn't another way. I'm planning to look more into this area of the dll later on this year, but I doubt that I could just look at the code for an hour and instantly understand why it is one way and not the other. Just like Charles, I've got other commitments which prevent me from studying the code and the way it interacts within the MS environment 24x7. So I might contend that, while your reply might be a valid one, my question is still a valid one. Cheers, Nicholas
RE: rebase problem for cygcurl-2.dll still existing?!
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas Wourms > Sent: Wednesday, 17 July 2002 10:09 PM > To: Jason Tishler > Cc: [EMAIL PROTECTED] > Subject: Re: rebase problem for cygcurl-2.dll still existing?! > > > Jason Tishler wrote: > > >>Is that a deficiency of cygwin as a whole, or just related > to the way > >>my DLL was built?) > >> > > > >Cygwin's fork() attempts to load DLLs in the child in the > same location > >as in the parent. If it fails, then the child aborts. > > > Other than the lack of someone writing the code, is there any > reason why > fork() can't automagically try another location? Is this > even possible? > Or does it go against the way Cygwin/Windows works? It goes against the way fork works. Take a pointer foo with value bar. After fork, *foo must equal *foo before the fork. If bar points into a dll, and the dll is mapped somewhere else, then after fork *foo != *foo before the fork. Rob
Re: rebase problem for cygcurl-2.dll still existing?!
Nicholas Wourms wrote: > > Jason Tishler wrote: > > >>Is that a deficiency of cygwin as a whole, or just related to the way > >>my DLL was built?) > >> > > > >Cygwin's fork() attempts to load DLLs in the child in the same location > >as in the parent. If it fails, then the child aborts. > > > Other than the lack of someone writing the code, is there any reason why > fork() can't automagically try another location? Is this even possible? > Or does it go against the way Cygwin/Windows works? > The correct answer to this question is "Use the source, Luke" (tm). Earnie.
Re: rebase problem for cygcurl-2.dll still existing?!
Jason Tishler wrote: >>Is that a deficiency of cygwin as a whole, or just related to the way >>my DLL was built?) >> > >Cygwin's fork() attempts to load DLLs in the child in the same location >as in the parent. If it fails, then the child aborts. > Other than the lack of someone writing the code, is there any reason why fork() can't automagically try another location? Is this even possible? Or does it go against the way Cygwin/Windows works? Cheers, Nicholas
Re: rebase problem for cygcurl-2.dll still existing?!
Kevin, On Tue, Jul 16, 2002 at 12:18:36PM -0400, Roth, Kevin P. wrote: > On one hand, I have CGF asking for stripping of all EXE/DLLs, to save > on disk space, and also download speed for our dial-up friends (I > assume). I stated that my preference was not to strip so that rebasing will work. If you strip, then my latest rebase will just skip cygcurl-2.dll but it will *not* corrupt it. > On the other hand I have Stipe noticing that his PHP package (if > memory serves) can't successfully rebase my cygcurl-2 dll, and > therefore doesn't work. See above. > (Though I thought rebasing was not necessarily required, since windows > normally relocates DLLs in memory when a collision occurs.) See below. > I'll be happy to repackage without stripping the DLL, if that's OK > with CGF-and-friends. Or if someone suggests another workable approach > I'll gladly oblige... If I hear nothing by tomorrow, I'll go ahead and > submit a non-stripped package until such time as this issue is > resolved. I will defer to Chris and/or the consensus regarding this issue. > (BTW: for any given version of cygcurl-2.dll, does rebasing need to > happen just once per target machine [e.g. when cygcurl-2.dll is > installed], or also every time something that depends on it [such as > PHP's curl wrapper] gets installed?) Actually every time a new DLL is installed on a system, it should be rebased so as not to collide with the other DLLs. This is why I need to integrate my stand-alone rebase into Cygwin's setup.exe. > (BTW2: can anyone explain in layman's terms why it is that in-memory > relocation upon collision doesn't happen in this case? It does. This is not the issue, Cygwin's fork() implementation is. > Is that a deficiency of cygwin as a whole, or just related to the way > my DLL was built?) Cygwin's fork() attempts to load DLLs in the child in the same location as in the parent. If it fails, then the child aborts. Jason
Re: rebase problem for cygcurl-2.dll still existing?!
Earnie, On Tue, Jul 16, 2002 at 12:31:52PM -0400, Earnie Boyd wrote: > Or, provide some means to accomplish an ignore this dll for the rebase > tool. This has already been implemented: http://cygwin.com/ml/cygwin/2002-07/msg00276.html Jason
Re: Guile-1.5.6-4 available for review/upload
On Tue, Jul 16, 2002 at 02:38:52PM +0200, [EMAIL PROTECTED] wrote: > Guile version 1.5.6-4, is now available for uploading at: Uploaded. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ITP] libungif-4.1.0-2
On Tue, Jul 16, 2002 at 05:44:33PM +0200, Lapo Luchini wrote: > >Yes, sometimes I do this; I have a "prep" and a "prep2" stage -- not a > >very creative or informative naming scheme, I'll admit. > >Yes, I think -3 is ready to upload; there's no need to futz with it > >any more. Just let 'er rip. > > As I sais earlier I didn't change the release for this very small > change, the url with the new files is still > http://www.lapo.it/tmp/libungif-4.1.0-2.tar.bz2 > http://www.lapo.it/tmp/libungif-4.1.0-2-src.tar.bz2 So, shall I upload it now? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
