[ANN] apache_1.3.22 package available for setup inclusion
Hi list, I have put up my recent work on the Apache HTTP server for inclusion to the official Cygwin setup.exe distribution to: http://apache.dev.wapme.net/support/apache-cygwin/ The setup.hint: sdesc: "The Apache HTTP (Web) Server" ldesc: "The Apache Project is a collaborative software development effort aimed at creating a robust, commercial-grade, featureful, and freely-available source code implementation of an HTTP (Web) server. The project is jointly managed by a group of volunteers located around the world, using the Internet and the Web to communicate, plan, and develop the server and its related documentation. These volunteers are known as the Apache Group. In addition, hundreds of users have contributed ideas, code, and documentation to the project. This file is intended to briefly describe the history of the Apache Group and recognize the many contributors." category: Net Web requires: cygwin curr: 1.3.22 The modules are pre-compiled as shared DLLs and the build process has been documented in /usr/doc/Cygwin/apache_1.3.22-1.README. Users may have to include /usr/libexec to their PATH, due to the fact that libhttpd.dll resides there. Should we move at least that core library to /usr/bin to have it in PATH like the other cygfoo.dlls? If somebody, probably Gerrit and Volker :)) would not mind to vote as testers. Have a look on it so that we get it announced ASAP. Any reports would be highly appritiated and should be reported to the list. BTW, this Apache for Cygwin port is maintained by me at the ASF (Apache Software Foundation) and is working very stable for several months now. The source tarballs includes the latest patch I send in for the current 1.3 cvs branch and hence users may undo the patch using the included diff file (as setup.html requires it to). Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
> http://apache.dev.wapme.net/support/apache-cygwin/ note that this server is running Apache 1.3.23-dev (Cygwin) :)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
> "Stipe" == Stipe Tolj <[EMAIL PROTECTED]> writes: Stipe> Hi list, Stipe> I have put up my recent work on the Apache HTTP server for inclusion Stipe> to the official Cygwin setup.exe distribution to: Stipe> http://apache.dev.wapme.net/support/apache-cygwin/ Stipe> If somebody, probably Gerrit and Volker :)) would not mind to vote as Stipe> testers. Have a look on it so that we get it announced ASAP. Any I'll give it a try :-) Stipe> reports would be highly appritiated and should be reported to the Stipe> list. Ciao Volker
Re: [ANN] apache_1.3.22 package available for setup inclusion
Excellent. I'm keen to see this available. I'll happily let Gerrit and/or Volker review the tarballs though :}. Rob
Fw: Delivery Status Notification (Failure)
Stipe, is the below your correct email address? Rob +AD0APQA9- - Original Message - From: +ADw-postmaster+AEA-itdomain.net.au+AD4- To: +ADw-robert.collins+AEA-itdomain.com.au+AD4- Sent: Wednesday, January 09, 2002 10:26 PM Subject: Delivery Status Notification (Failure) +AD4- This is an automatically generated Delivery Status Notification. +AD4- +AD4- Delivery to the following recipients failed. +AD4- +AD4-tolj+AEA-wapme-systems.de +AD4- +AD4- +AD4- +AD4- ATT01527.dat Description: Binary data --- Begin Message --- Excellent. I'm keen to see this available. I'll happily let Gerrit and/or Volker review the tarballs though :}. Rob --- End Message ---
Re: whois package
- Original Message - From: "Mark Bradshaw" <[EMAIL PROTECTED]> > Just wanted to drop in a reminder about the whois package. Could I get an > official/unofficial nanny to check it over, or at least a note telling me to > shut up til people have more time? Looks OK Mark. Does it build OOTB? I ask because the source archive has no CYGWIN_PATCHES directory in it. If it doesn't build OOTB then the place to put your patch is in CYGWIN_PATCHES/ in the src archive, along with a README about what's needed to recreate the binary package (for folk building custom versions - i.e. with different configure switches. Once that's answered/corrected, then I'll uplaod for you. As a side note... you might be interested in utilising one of Chuck's scripts for the packaging process - grab the source tarball for nearly any of his packages, or the src tarball for libxsl (which has a script I customised from Chucks), and a lot of the mechanics can be automated easily. Rob
Re: autotool man and info pages
- Original Message - From: "Charles Wilson" <[EMAIL PROTECTED]> > I think some of my earlier test versions didn't "do it right" -- but the > current versions do. Try "reinstalling" from the net (not from your > local repository). >autoconf-devel-2.52-4 >automake-devel-1.5-5 Whaddya, know, info autoconf works now... I should retested before emailing. (I was already on the versions shown below). Rob Administrator@LIFELESSWKS /usr/src/package $ cygcheck -c autoconf-devel Cygwin Package Information Package Version autoconf-devel 2.52-4 Use -h to see help about each section Administrator@LIFELESSWKS /usr/src/package $ cygcheck -c automake-devel Cygwin Package Information Package Version automake-devel 1.5-5 Use -h to see help about each section
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 09:16:12AM +0100, Stipe Tolj wrote: > Users may have to include /usr/libexec to their PATH, due to the fact > that libhttpd.dll resides there. Should we move at least that core > library to /usr/bin to have it in PATH like the other cygfoo.dlls? Shouldn't that be /usr/bin/cyghttpd.dll? ^^^ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe, 2002-01-09 12:17:13, du schriebst: > http://apache.dev.wapme.net/support/apache-cygwin/ > The setup.hint: > sdesc: "The Apache HTTP (Web) Server" > ldesc: "The Apache Project is a collaborative software development > effort aimed at creating a robust, commercial-grade, featureful, > and freely-available source code implementation of an HTTP (Web) > server. The project is jointly managed by a group of volunteers > located around the world, using the Internet and the Web to > communicate, plan, and develop the server and its related > documentation. These volunteers are known as the Apache Group. > In addition, hundreds of users have contributed ideas, code, and > documentation to the project. This file is intended to briefly > describe the history of the Apache Group and recognize the many > contributors." > category: Net Web > requires: cygwin > curr: 1.3.22 > The modules are pre-compiled as shared DLLs and the build process has > been documented in /usr/doc/Cygwin/apache_1.3.22-1.README. > Users may have to include /usr/libexec to their PATH, due to the fact > that libhttpd.dll resides there. Should we move at least that core > library to /usr/bin to have it in PATH like the other cygfoo.dlls? I vote pro including this package to the net release (mainly because there is another proxyserver which works better for me like squid;) The binary version seems to work ok, as usual (proxy not tested yet). Some minor issues: 1. I think libhttpd.dll should be in /usr/bin like all the shared libs. To load the shared plugins it isn't needed to include /usr/libexec in the PATH? 1.2. # Cygwin 1.3.x layout prefix:/usr exec_prefix: $prefix bindir:$prefix/bin sbindir: $prefix/sbin libexecdir:$prefix/libexec mandir:$prefix/man sysconfdir:/etc/httpd/conf I request to change the path to the conf files to /etc/apache or /etc/httpd, why another subdirectory? datadir: /var/www iconsdir: $datadir/icons htdocsdir: $datadir/htdocs manualdir: $htdocsdir/manual cgidir:$datadir/cgi-bin includedir:$prefix/include/apache localstatedir: /var runtimedir:$localstatedir/run logfiledir:$localstatedir/log/httpd proxycachedir: $localstatedir/cache/httpd 2. A typo in the README: tar xjvf apache_1.3.22-1-src.tar.bz2 cd apache_1.3.22 configure --with-layour=Cygwin \ ^ --with-port=80 \ --enable-module=most \ --enable-shared=max 3. The Cygwin README with build instructions should also be included in the source package (IMO). Fix 1., 2., 3. and i'll start a build now to see if the patched source builds `user-friendly' without tweaking:-) Gerrit -- =^..^=
Re: [ANN] apache_1.3.22 package available for setup inclusion
=== - Original Message - From: "Gerrit P. Haase" <[EMAIL PROTECTED]> > > (mainly because > there is another proxyserver which works better for me like squid;) I'm not sure what you mean here Gerrit - are you saying Squid is better for you than apache (in proxy mode), or something else? Rob
Re: [ANN] apache_1.3.22 package available for setup inclusion
Corinna, 2002-01-09 12:50:02, du schriebst: > On Wed, Jan 09, 2002 at 09:16:12AM +0100, Stipe Tolj wrote: >> Users may have to include /usr/libexec to their PATH, due to the fact >> that libhttpd.dll resides there. Should we move at least that core >> library to /usr/bin to have it in PATH like the other cygfoo.dlls? > Shouldn't that be /usr/bin/cyghttpd.dll? >^^^ It is the same like it is with perl or python. These packages doesn't use libtool and to change the name would need some additional patches in a lot of build related files which would blow up the patch. But I'll look what I can do regarding the next perl release. Gerrit -- =^..^=
tetex-beta-20001218 available for testing
I have just put a new rebuilt of tetex-beta-20001218 for test. A more mature version will be made out in accordance with a texmf package. Thanks for your reports, Jerome BENOIT
Re: [ANN] apache_1.3.22 package available for setup inclusion
Robert, 2002-01-09 13:04:30, du schriebst: >> (mainly because >> there is another proxyserver which works better for me like squid;) > I'm not sure what you mean here Gerrit - are you saying Squid is better > for you than apache (in proxy mode), or something else? Though I think squid is a little faster, I prefer the Apache proxy where I had never troubles in setting up like I had with squid. You start Apache and the proxy works (after activating the relevant part in httpd.conf). I really don't know which is 'better' in general;) Also I run an instance of Apache the most time, so I don't need to fire up another server process just to have a proxy. Gerrit -- =^..^=
Re: [ANN] apache_1.3.22 package available for setup inclusion
- Original Message - From: "Gerrit P. Haase" <[EMAIL PROTECTED]> > Robert, > > 2002-01-09 13:04:30, du schriebst: > > >> (mainly because > >> there is another proxyserver which works better for me like squid;) > > > I'm not sure what you mean here Gerrit - are you saying Squid is better > > for you than apache (in proxy mode), or something else? > > Though I think squid is a little faster, I prefer the Apache proxy where > I had never troubles in setting up like I had with squid. You start > Apache and the proxy works (after activating the relevant part in > httpd.conf). > > I really don't know which is 'better' in general;) I do :}. Squid is a dedicated proxy/web accelerator, and it does that quite well :]. I'd be quite interested to know how much RAM apache needed to run a 30-40Gb cache. Also, from a security point of view, having your web server and proxy different is a very good idea. Apache's proxying is getting better, but still (IMO) not up to scratch. > Also I run an instance of Apache the most time, so I don't need to fire > up another server process just to have a proxy. Sure. I tend to run both, but to each their own. Disclaimer: I'm a core squid developer. Rob
Re: tetex-beta-20001218 available for testing
"Jérôme-Georges-Michel BENOIT" <[EMAIL PROTECTED]> writes: > I have just put a new rebuilt of tetex-beta-20001218 > for test. Thanks. Any chance for us earthlings being able download this today? [is there any 'direct mirror?'] > A more mature version will be made out in accordance > with a texmf package. I'll try to get a first texmf package out asap. Jan. -- Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe, 2002-01-09 13:10:34, du schriebst: and i'll start a build now to see if the > patched source builds `user-friendly' without tweaking:-) Intro: == $ cygcheck libhttpd.dll Found: .\libhttpd.dll Found: C:\cygwin\bin\libhttpd.dll .\libhttpd.dll .\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL Question 1: === The Apache isn't linked against libgdbm? Wouldn't it be a nice addition? I ask because of this message during configuring: + adding selected modules o rewrite_module uses ConfigStart/End disabling DBM support for mod_rewrite (perhaps you need to add -ldbm, -lndbm or -lgdbm to EXTRA_LIBS) o dbm_auth_module uses ConfigStart/End Question 2: === My configure says: + using system Expat wouldn't it be nice to have a cygwin-port of expat with shared libs too? Question 3: === Is it useful to link in libcrypt? What about https support for the proxy, is it possible, is it already included? Need I to add libssl & libcrypto somewhere? Gerrit -- =^..^=
Re: [ANN] apache_1.3.22 package available for setup inclusion
Robert, 2002-01-09 13:29:59, du schriebst: >> I really don't know which is 'better' in general;) > I do :}. Squid is a dedicated proxy/web accelerator, and it does that > quite well :]. I'd be quite interested to know how much RAM apache > needed to run a 30-40Gb cache. Well, I have no needs like this, my wife and me we are using two PC's, mine has a direct connection and her box connects via my server to the net, so there is not much to do for the proxy. > Also, from a security point of view, having your web server and proxy > different is a very good idea. That is important! But not for me yet (with a dial up connection). > Disclaimer: I'm a core squid developer. Ach so;) Gerrit -- =^..^=
Re: tetex-beta-20001218 available for testing
Jérôme-Georges-Michel, 2002-01-09 13:34:00, du schriebst: > I have just put a new rebuilt of tetex-beta-20001218 > for test. Where do I get it? Gerrit -- =^..^=
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe, 2002-01-09 13:36:24, du schriebst: > 2. > A typo in the README: > tar xjvf apache_1.3.22-1-src.tar.bz2 > cd apache_1.3.22 > configure --with-layour=Cygwin \ > ^ > --with-port=80 \ > --enable-module=most \ > --enable-shared=max > 3. > The Cygwin README with build instructions should also > be included in the source package (IMO). Ah, I saw now, the README states: To build the application for cygwin: tar xjvf apache_1.3.22-1-src.tar.bz2 cd apache_1.3.22 configure --with-layout=Cygwin \ --with-port=80 \ --enable-module=most --enable-shared=max make make make install Perhaps you should point out explicitely that `make' needs to run two times here. Gerrit -- =^..^=
Cygwin Python cyg vs. lib (was Re: [ANN] apache_1.3.22 package ...)
On Wed, Jan 09, 2002 at 12:52:45PM +0100, Gerrit P. Haase wrote: > 2002-01-09 12:50:02, du schriebst: > > > On Wed, Jan 09, 2002 at 09:16:12AM +0100, Stipe Tolj wrote: > >> Users may have to include /usr/libexec to their PATH, due to the fact > >> that libhttpd.dll resides there. Should we move at least that core > >> library to /usr/bin to have it in PATH like the other cygfoo.dlls? > > > Shouldn't that be /usr/bin/cyghttpd.dll? > > It is the same like it is with perl or python. When I did the initial patch to build Cygwin Python with a DLL core to support shared (i.e., DLL) extension modules I didn't want to fight this battle with the upstream maintainers too. IIRC, using the "cyg" prefix instead of "lib" would have complicated the Makefiles. Besides the Win32 DLL are called pythonXY.dll instead of libpythonX.Y.dll, so there is no chance of a name clash. Subsequently, the Python Makefiles have been significantly changed. I just checked and it appears (at first glance) that using the "cyg" prefix should not affect any other platform. Should I submit a patch to invoke this change? Or, should I let sleeping dogs lie? Jason
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 01:27:47PM +0100, Gerrit P. Haase wrote: > Question 3: > === > Is it useful to link in libcrypt? Ack! You mean libcrypto/libssl, not libcrypt (which consists entirely of the 56bit DES routines), right? Corinna > What about https support for the proxy, is it possible, is it already included? > Need I to add libssl & libcrypto somewhere? > > > Gerrit > -- > =^..^= -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
"Gerrit P. Haase" wrote: > Some minor issues: > > 1. > I think libhttpd.dll should be in /usr/bin like all the shared libs. > To load the shared plugins it isn't needed to include /usr/libexec in > the PATH? So we would need to include all libfoo.dll and mod_bar.dll's to /usr/bin, right?! Any objections from the others? If not, I will re-build the package to apache_1.3.22-2. > 1.2. > # Cygwin 1.3.x layout > > prefix:/usr > exec_prefix: $prefix > bindir:$prefix/bin > sbindir: $prefix/sbin > libexecdir:$prefix/libexec > mandir:$prefix/man > sysconfdir:/etc/httpd/conf > > I request to change the path to the conf files to /etc/apache or > /etc/httpd, why another subdirectory? I took RedHat's layout which is the same. SuSE by the other hand uses /etc/httpd only. The only thing I can imagine why to add conf/ here is to allow additional sub-directories that are needed for certain Apache extension modules, i.e. JServ and Tomcat are heavy using config files (properties, etc.), these may be going to /etc/httpd/jserv or tomcat, etc. Heads up please who whishes a change of sysconfdir to /etc/httpd, even while I dis-agree a bit on this. > 2. > A typo in the README: > tar xjvf apache_1.3.22-1-src.tar.bz2 > cd apache_1.3.22 > configure --with-layour=Cygwin \ > ^ > --with-port=80 \ > --enable-module=most \ > --enable-shared=max ups, this needs fixing of course. -- scheduled. > 3. > The Cygwin README with build instructions should also > be included in the source package (IMO). > > Fix 1., 2., 3. and i'll start a build now to see if the > patched source builds `user-friendly' without tweaking:-) I'll fix 1. and 3. and re-post ASAF. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
"Gerrit P. Haase" wrote: > > Corinna, > > 2002-01-09 12:50:02, du schriebst: > > > On Wed, Jan 09, 2002 at 09:16:12AM +0100, Stipe Tolj wrote: > >> Users may have to include /usr/libexec to their PATH, due to the fact > >> that libhttpd.dll resides there. Should we move at least that core > >> library to /usr/bin to have it in PATH like the other cygfoo.dlls? > > > Shouldn't that be /usr/bin/cyghttpd.dll? > >^^^ > > It is the same like it is with perl or python. These packages > doesn't use libtool and to change the name would need some additional > patches in a lot of build related files which would blow up the patch. yep, Gerrit is right here. I may change it if absolutely required, but it has to be patched in the Makefile.tmpl's and the main src/Configure script. Is it _absolutely_ required? setup.html does not state it, IMO?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Cygwin Python cyg vs. lib (was Re: [ANN] apache_1.3.22 package ...)
Jason Tishler wrote: > > On Wed, Jan 09, 2002 at 12:52:45PM +0100, Gerrit P. Haase wrote: > > 2002-01-09 12:50:02, du schriebst: > > > > > On Wed, Jan 09, 2002 at 09:16:12AM +0100, Stipe Tolj wrote: > > >> Users may have to include /usr/libexec to their PATH, due to the fact > > >> that libhttpd.dll resides there. Should we move at least that core > > >> library to /usr/bin to have it in PATH like the other cygfoo.dlls? > > > > > Shouldn't that be /usr/bin/cyghttpd.dll? > > > > It is the same like it is with perl or python. > > When I did the initial patch to build Cygwin Python with a DLL core to > support shared (i.e., DLL) extension modules I didn't want to fight this > battle with the upstream maintainers too. that true for the Apache Group too, I guess. It's hard enough to get the Cygwin related patches to the stable cvs tree, at least the 1.3 tree, which is something like "the gold box" for ASF :)) My basical approach is to get everything related to Cygwin from Apache to the official source tree and hence this would raise the quistions: "Hmm, and why do you guys on Cygwin need cygfoo.dll instead of havin libfoo.dll? I don't see any need." and then the discussion begins... :) Just my 2ct on that. > prefix should not affect any other platform. Should I submit a patch > to invoke this change? Or, should I let sleeping dogs lie? Same for me at the Apache front here. If the we commit that all shared libraries _have to_ be cygfoo.dll named, I'll do it for Apache. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 03:53:44PM +0100, Stipe Tolj wrote: > "Gerrit P. Haase" wrote: > > 1.2. > > # Cygwin 1.3.x layout > > > > prefix:/usr > > exec_prefix: $prefix > > bindir:$prefix/bin > > sbindir: $prefix/sbin > > libexecdir:$prefix/libexec > > mandir:$prefix/man > > sysconfdir:/etc/httpd/conf > > > > I request to change the path to the conf files to /etc/apache or > > /etc/httpd, why another subdirectory? > > I took RedHat's layout which is the same. SuSE by the other hand uses > /etc/httpd only. Uhm, you both *did* look onto http://cygwin.com/setup.html#package_contents, right? You''l find the following configure options as default options: --prefix=/usr --sysconfdir=/etc --libexecdir='$(sbindir)' --localstatedir=/var --datadir='$(prefix)/share' I'd agree to change the sysconfdir to sth. below /etc as /etc/httpd but I don't see a reason to change libexecdir. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
Robert Collins wrote: > I do :}. Squid is a dedicated proxy/web accelerator, and it does that > quite well :]. I'd be quite interested to know how much RAM apache > needed to run a 30-40Gb cache. Robert is right here. The Apache group has stated a couple of times that squid is performing way more better then Apache's proxy module. To be noted: Apache group does currently almost not maintain the proxy module anymore. > Disclaimer: I'm a core squid developer. So you should be disqualified here, I guess :] Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 03:56:36PM +0100, Stipe Tolj wrote: > "Gerrit P. Haase" wrote: > > > > Corinna, > > > > 2002-01-09 12:50:02, du schriebst: > > > > > On Wed, Jan 09, 2002 at 09:16:12AM +0100, Stipe Tolj wrote: > > >> Users may have to include /usr/libexec to their PATH, due to the fact > > >> that libhttpd.dll resides there. Should we move at least that core > > >> library to /usr/bin to have it in PATH like the other cygfoo.dlls? > > > > > Shouldn't that be /usr/bin/cyghttpd.dll? > > >^^^ > > > > It is the same like it is with perl or python. These packages > > doesn't use libtool and to change the name would need some additional > > patches in a lot of build related files which would blow up the patch. > > yep, Gerrit is right here. > > I may change it if absolutely required, but it has to be patched in > the Makefile.tmpl's and the main src/Configure script. > > Is it _absolutely_ required? setup.html does not state it, IMO?! I would not like to force users to add $libexecdir to their path. Either the dll is loaded eplicitely at runtime or it's linked in so that it's inherently loaded at application start. In the first case you can even put the lib into /usr/lib (which would then make sense, IMO). In the second case it should go to /usr/bin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
"Gerrit P. Haase" wrote: > Question 1: > === > The Apache isn't linked against libgdbm? > Wouldn't it be a nice addition? > > I ask because of this message during configuring: > > + adding selected modules > o rewrite_module uses ConfigStart/End > disabling DBM support for mod_rewrite > (perhaps you need to add -ldbm, -lndbm or -lgdbm to EXTRA_LIBS) > o dbm_auth_module uses ConfigStart/End snap from src/Configure: ... *-cygwin*) OS='Cygwin' OSDIR="os/cygwin" CFLAGS="$CFLAGS -DCYGWIN" DEF_WANTHSREGEX=yes DBM_LIB="-lgdbm" LIBS="$LIBS -lcrypt $DBM_LIB" ;; ... so it should be linked in, IMO, but staticaly. Should be link against the import lib -lgsbm.dll to have cyggdbm.dll used? > Question 2: > === > My configure says: > > + using system Expat > > wouldn't it be nice to have a cygwin-port of expat with shared libs too? expat is not maintained by the Apache group itself, so it's an other front here I guess. > Question 3: > === > Is it useful to link in libcrypt? > What about https support for the proxy, is it possible, is it already included? https means SSL-enabled HTTP, which requires mod_ssl (or equivalent other module) to be included. CAMP uses mod_ssl, but it's not part of the core source distribution, but works OOTB for Cygwin :) > Need I to add libssl & libcrypto somewhere? only for mod_ssl. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
> Ah, I saw now, the README states: > To build the application for cygwin: > > tar xjvf apache_1.3.22-1-src.tar.bz2 > cd apache_1.3.22 > configure --with-layout=Cygwin \ > --with-port=80 \ > --enable-module=most --enable-shared=max > make > make > make install > > Perhaps you should point out explicitely that `make' needs to run two > times here. I don't see what is more explicit than stating the shell commands that have to be used?! Even if I admit that this _may_ be missed by someone, while the first make there _is_ a special screen showing that. Have you tried that? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
> --prefix=/usr > --sysconfdir=/etc > --libexecdir='$(sbindir)' > --localstatedir=/var > --datadir='$(prefix)/share' > > I'd agree to change the sysconfdir to sth. below /etc as /etc/httpd > but I don't see a reason to change libexecdir. So you want to keep the *.dlls in /usr/libexec? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 04:17:54PM +0100, Stipe Tolj wrote: > > --prefix=/usr > > --sysconfdir=/etc > > --libexecdir='$(sbindir)' > > --localstatedir=/var > > --datadir='$(prefix)/share' > > > > I'd agree to change the sysconfdir to sth. below /etc as /etc/httpd > > but I don't see a reason to change libexecdir. > > So you want to keep the *.dlls in /usr/libexec? No. See my other mail. What I meant was, $libexecdir should be == $sbindir == $(prefix)/sbin == /usr/sbin. DLLs to /usr/libif run time loaded with e.g. dlopen() /usr/binif inherently linked in. Basically I don't want /usr/libexec in the users path. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
> No. See my other mail. What I meant was, $libexecdir should be > == $sbindir == $(prefix)/sbin == /usr/sbin. > > DLLs to > > /usr/libif run time loaded with e.g. dlopen() > /usr/binif inherently linked in. > > Basically I don't want /usr/libexec in the users path. Ok, so we'll have to have: /usr/lib/libfoo.dll /usr/lib/mod_bar.dll for the run time loaded modules, and /usr/bin/libhttpd.dll for the inherently linked in core lib. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
On the location of DLLs: I agree with Corinna that "inherently linked" DLL's should be in /usr/bin, and should be named "cygX.dll" not "libX.dll". However, I don't think it TRULY matters where dlopen'ed DLLs live -- except that users should not have to add /usr/libexec (or /usr/lib/perl5/cygwin-multi/auto/ByteLoader/ and /usr/lib/perl5/cygwin-multi/auto/Data/Dumper/ and ...) to their path. Also, I do not think that private, dlopened, not-in-the-public-bin-directory DLLs should be forced to follow the cyg.dll nomenclature. .dll, lib.dll, whatever. They're *private* -- who cares what they are named (although .dll is kindof a necessity due to windows runtime loader and dlopen issues) The fact is, many packages put private, non-linkable, unusable-except-by-themselves shared libs into some private structure. Like perl does. This is okay, IMO. However, packages that do this should not require "external assistance" to find those dlopen'ed shared libs. Either they should be dlopen'ed using the full path, or main() should add the requisite directories to the PATH -- but only for its process space, not globally. So, IMO it's fine if apache puts its private, dlopen'ed DLLs into /usr/libexec/apache/modules or whereever -- but it should not require that /usr/libexec/apache/modules be added to the global PATH. Now, if apache's httpd.exe is inherently linked to LOTS of mod_*.dll shared libs -- instead of dlopen'ing them -- then I think that's a poor design decision and apache needs a bit more work to change that to using dlopen for the module-related DLL's...otherwise, where's the benefit of using DLL's? You still need to relink httpd.exe every time you add a new module...might as well use static libs. --Chuck Corinna Vinschen wrote: > On Wed, Jan 09, 2002 at 04:17:54PM +0100, Stipe Tolj wrote: > >>> --prefix=/usr >>> --sysconfdir=/etc >>> --libexecdir='$(sbindir)' >>> --localstatedir=/var >>> --datadir='$(prefix)/share' >>> >>>I'd agree to change the sysconfdir to sth. below /etc as /etc/httpd >>>but I don't see a reason to change libexecdir. >>> >>So you want to keep the *.dlls in /usr/libexec? >> > > No. See my other mail. What I meant was, $libexecdir should be > == $sbindir == $(prefix)/sbin == /usr/sbin. > > DLLs to > > /usr/lib if run time loaded with e.g. dlopen() > /usr/bin if inherently linked in. > > Basically I don't want /usr/libexec in the users path. > > Corinna > >
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe Tolj wrote: > > > No. See my other mail. What I meant was, $libexecdir should be > > == $sbindir == $(prefix)/sbin == /usr/sbin. > > > > DLLs to > > > > /usr/libif run time loaded with e.g. dlopen() > > /usr/binif inherently linked in. > > > > Basically I don't want /usr/libexec in the users path. > > Ok, so we'll have to have: > > /usr/lib/libfoo.dll > /usr/lib/mod_bar.dll > > for the run time loaded modules, and > > /usr/bin/libhttpd.dll > > for the inherently linked in core lib. > The long stated rule, check this and cygwin-developers archives, is that Cygwin dependent dll's must begin with the prefix `cyg'. Please maintain this standard, the reasons have been documented in the archives. Chuck even patched binutils to make it as easy as possible to prefix the dll output. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 04:38:12PM +0100, Stipe Tolj wrote: > > No. See my other mail. What I meant was, $libexecdir should be > > == $sbindir == $(prefix)/sbin == /usr/sbin. > > > > DLLs to > > > > /usr/libif run time loaded with e.g. dlopen() > > /usr/binif inherently linked in. > > > > Basically I don't want /usr/libexec in the users path. > > Ok, so we'll have to have: > > /usr/lib/libfoo.dll > /usr/lib/mod_bar.dll > > for the run time loaded modules, and > > /usr/bin/libhttpd.dll > > for the inherently linked in core lib. Yep. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe Tolj wrote: >>>Shouldn't that be /usr/bin/cyghttpd.dll? >>> ^^^ >>> >>It is the same like it is with perl or python. These packages >>doesn't use libtool and to change the name would need some additional >>patches in a lot of build related files which would blow up the patch. >> > > yep, Gerrit is right here. > > I may change it if absolutely required, but it has to be patched in > the Makefile.tmpl's and the main src/Configure script. > > Is it _absolutely_ required? setup.html does not state it, IMO?! Suppose you had both a native apache port and a cygwin apache port. Assume both were built "shared" -- so both had a "libhttpd.dll" shared library. However, one is msvcrt.dll based, the other cygwin1.dll based. Because the respective httpd.exe's are inherently linked to these DLL's, both require that the dirs containing those DLLs are in the global system path -- but one of them must come first, since there's only one global system path. This can often cause problems, with the wrong DLL being used, and the app crashes on startup. I ran into this problem with libz.dll, libpng.dll, libjpeg.dll, and others -- prior to the 'cyg' switchover. MikTeX distributes a native port of netpbm with these graphics/compression DLLs -- yet I already had DLLs with the same name in c:\cygwin\bin (which is in my system PATH). Big time BOOM! The reason we require 'cyg' prefix instead of 'lib' on DLLs that live in /usr/bin is precisely to avoid this problem. cygwin must coexist with native and other unix-emulation platforms all on the same machine -- which means we need to distinguish our shared libs from theirs. I believe there is NO other "platform" -- except windows/pw/mingw/cygwin/uwin -- that ever experience this problem. Doncha love being unique? -- Chuck
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe Tolj wrote: > "Gerrit P. Haase" wrote: > > >>Question 1: >>=== >>The Apache isn't linked against libgdbm? >>Wouldn't it be a nice addition? >> >>I ask because of this message during configuring: >> >> + adding selected modules >>o rewrite_module uses ConfigStart/End >> disabling DBM support for mod_rewrite >> (perhaps you need to add -ldbm, -lndbm or -lgdbm to EXTRA_LIBS) >>o dbm_auth_module uses ConfigStart/End >> > > snap from src/Configure: > > ... > *-cygwin*) > OS='Cygwin' > OSDIR="os/cygwin" > CFLAGS="$CFLAGS -DCYGWIN" > DEF_WANTHSREGEX=yes > DBM_LIB="-lgdbm" > LIBS="$LIBS -lcrypt $DBM_LIB" > ;; > ... > > so it should be linked in, IMO, but staticaly. Actually, -lgdbm SHOULD result in a dynamic link. unless you explicitly say '-static', ld will first attempt to link against "libgdbm.dll.a" (the import lib for cyggdbm.dll) BEFORE trying to link against "libgdbm.a" (the static lib). > Should be link against the import lib -lgsbm.dll to have cyggdbm.dll > used? No, see above. (Also, the current gdbm DLLization is "old style" -- which means that if you want to link STATICALLY you have to compile with -DGDBM_STATIC. See /usr/doc/Cygwin/gdbm.README. I hope to change this soon...utilizing autoimport functionality, blah blah blah) > > >>Question 2: >>=== >>My configure says: >> >> + using system Expat >> >>wouldn't it be nice to have a cygwin-port of expat with shared libs too? >> > > expat is not maintained by the Apache group itself, so it's an other > front here I guess. True -- are you volunteering, Gerrit? :-) --Chuck
Re: [ANN] apache_1.3.22 package available for setup inclusion
> Suppose you had both a native apache port and a cygwin apache port. > Assume both were built "shared" -- so both had a "libhttpd.dll" shared > library. However, one is msvcrt.dll based, the other cygwin1.dll based. > Because the respective httpd.exe's are inherently linked to these > DLL's, both require that the dirs containing those DLLs are in the > global system path -- but one of them must come first, since there's > only one global system path. mop, the Win32 native ports of Apache use ApacheCore.dll and ApacheFooBar.dll name structures for the shared libs. Cuck, I have thought of that :)) -- this is no praise for my qualification, I guess :) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
Charles, 2002-01-09 17:20:32, du schriebst: [expat] > True -- are you volunteering, Gerrit? :-) Well, I tried to build it with minimal effort, but it failed, now I have done it like Robert with the libx*-packages and I have a patch file with about 600KB:-( If that doesn't matter, I'll contribute it, just let me create (or copy & paste) a build script. I posted the link to the patch at cygwin@ list this noon. Gerrit -- =^..^=
Apache Problem (was: Re: [ANN] apache_1.3.22 package available for setup inclusion)
Stipe, 2002-01-09 16:32:57, du schriebst: >> Question 1: >> === >> The Apache isn't linked against libgdbm? >> Wouldn't it be a nice addition? >> >> I ask because of this message during configuring: >> >> + adding selected modules >> o rewrite_module uses ConfigStart/End >> disabling DBM support for mod_rewrite >> (perhaps you need to add -ldbm, -lndbm or -lgdbm to EXTRA_LIBS) >> o dbm_auth_module uses ConfigStart/End > snap from src/Configure: > ... > *-cygwin*) > OS='Cygwin' > OSDIR="os/cygwin" > CFLAGS="$CFLAGS -DCYGWIN" > DEF_WANTHSREGEX=yes > DBM_LIB="-lgdbm" > LIBS="$LIBS -lcrypt $DBM_LIB" > ;; > ... > so it should be linked in, IMO, but staticaly. > Should be link against the import lib -lgsbm.dll to have cyggdbm.dll > used? Hmmm, have you tried to verify if this module is working because it looks weird if the configure states that it will disable this module? I think this message shouldn't be displayed if the options you quoted above were seen by ./configure. I added -lgdbm to src/Configuration.apaci and then it shows up correct during configure. Have you logs of your build? I get this during compiling the modules: gcc -c -I../os/cygwin -I../include -DCYGWIN -DNO_DBM_REWRITEMAP -DUSE_HSREGEX -DSHARED_CORE -O2 ^^^ obviously dbm_rewritemap is disabled, I guess it will not work if the module is compiled like that! And my libhttpd.dll is a little (50k!) smaller than your dll. Does it depend on the versions of expat I'm using? Your DLL (already stripped): $ ls -l usr/libexec/libhttpd.dll -rwxrwxrwx1 Gerrit Kein 289792 Jan 9 16:43 usr/libexec/libhttpd.dll* $ cygcheck libhttpd.dll .\libhttpd.dll .\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL My DLL (stripped): -rwxr-xr-x1 Gerrit Kein 234496 Jan 9 16:42 /bin/libhttpd.dll $ cygcheck src/libhttpd.dll src/libhttpd.dll C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL The modules are linked against the dll's: Use -h to see help about each section Found: .\mod_auth_dbm.dll .\mod_auth_dbm.dll C:\cygwin\bin\cygwin1.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\cygwin\bin\cyggdbm.dll C:\cygwin\bin\libhttpd.dll But I found no hint where expat-dll is linked with. I suggest we add -lgdbm to EXTRA_LIBS in src/Configuration.apaci so mod_auth_dbm gets compiled correct. Gerrit -- =^..^=
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 10:44:25AM -0500, Earnie Boyd wrote: > Stipe Tolj wrote: > > > > > No. See my other mail. What I meant was, $libexecdir should be > > > == $sbindir == $(prefix)/sbin == /usr/sbin. > > > > > > DLLs to > > > > > > /usr/libif run time loaded with e.g. dlopen() > > > /usr/binif inherently linked in. > > > > > > Basically I don't want /usr/libexec in the users path. > > > > Ok, so we'll have to have: > > > > /usr/lib/libfoo.dll > > /usr/lib/mod_bar.dll > > > > for the run time loaded modules, and > > > > /usr/bin/libhttpd.dll > > > > for the inherently linked in core lib. > > > > The long stated rule, check this and cygwin-developers archives, is that > Cygwin dependent dll's must begin with the prefix `cyg'. Please > maintain this standard, the reasons have been documented in the > archives. Chuck even patched binutils to make it as easy as possible to > prefix the dll output. I agree with Earnie, especially if the httpd lib is used to link with other applications, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe,
2002-01-09 18:42:41, du schriebst:
*-cygwin*)
DEF_SHARED_CORE=yes
LDFLAGS_SHLIB="--export-all"
LDFLAGS_MOD_SHLIB=$LDFLAGS_SHLIB
SHLIB_SUFFIX_NAME=dll
SHMOD_SUFFIX_NAME=dll
SHLIB_SUFFIX_DEPTH=0
LD_SHLIB='dllwrap'
LD_SHCORE_DEF=''
LD_SHCORE_LIBS="$LIBS"
LIBS_SHLIB='$(EXTRA_LIBS)'
SHARED_CORE_EP='lib$(TARGET).ep'
SHCORE_IMPLIB='lib$(TARGET).dll'
OS_MODULE_INCLUDE='$(SRCDIR)/modules/standard/Makefile.Cygwin'
;;
Notes:
- change SHCORE_IMPLIB='lib$(TARGET).dll' to
SHCORE_IMPLIB='cyg$(TARGET).dll'
and we have the right prefix;)
Gerrit
--
=^..^=
Re: Apache Problem (was: Re: [ANN] apache_1.3.22 package available for setup inclusion)
Gerrit, 2002-01-09 18:57:17, du schriebst: > I suggest we add -lgdbm to EXTRA_LIBS in src/Configuration.apaci so > mod_auth_dbm gets compiled correct. Well it needs to be added elsewhere, Configuration.apaci is generated from...? Configuration.tmpl? Gerrit -- =^..^=
Re: [ANN] apache_1.3.22 package available for setup inclusion
Gerrit, 2002-01-09 19:07:04, du schriebst: > Notes: > - change SHCORE_IMPLIB='lib$(TARGET).dll' to > SHCORE_IMPLIB='cyg$(TARGET).dll' > and we have the right prefix;) Ah no, it doesn't work that easy, why is the prefix hardcoded? Gerrit -- begin signature: =^..^= end
ITP: libtool-devel, libtool-stable, libtool (wrappers)
Preliminary versions are here:
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
See this message (and the thread that follows it) for more info:
http://cygwin.com/ml/cygwin-apps/2001-12/msg00179.html
Although I will support these packages -- as "cygwin applications" I do
NOT intend to answer "how do I use libtool" questions. I will silently
drop any message to the cygwin list concerning these packages that I
believe are *libtool* questions and not *cygwin* questions -- without
even a "go ask on the libtool mailing list" reply.
1) is the above attitude acceptable? If not, then is anybody else
willing to take over those packages and "ITP" them?
2) is "rc6" okay for a ${REL} number, or should it be a pure number?
(p.s. 'rc' means "robert collins hack" not "release candidate")
--Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
On Wed, Jan 09, 2002 at 01:21:02PM -0500, Charles Wilson wrote:
>Preliminary versions are here:
>
> http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
>
>See this message (and the thread that follows it) for more info:
>
>http://cygwin.com/ml/cygwin-apps/2001-12/msg00179.html
>
>Although I will support these packages -- as "cygwin applications" I do
>NOT intend to answer "how do I use libtool" questions. I will silently
>drop any message to the cygwin list concerning these packages that I
>believe are *libtool* questions and not *cygwin* questions -- without
>even a "go ask on the libtool mailing list" reply.
>
>1) is the above attitude acceptable? If not, then is anybody else
>willing to take over those packages and "ITP" them?
>2) is "rc6" okay for a ${REL} number, or should it be a pure number?
>(p.s. 'rc' means "robert collins hack" not "release candidate")
upset will do the right thing with it. I just checked. It even seems to
properly support rc6 vs. rc7.
I don't have any problems with it but it *is* a departure from the
guidelines in http://cygwin.com/setup.html, I believe.
I'll let Robert make the executive decision on this one, I think.
cgf
Re: [ANN] apache_1.3.22 package available for setup inclusion
Stipe Tolj wrote: > > > Suppose you had both a native apache port and a cygwin apache port. > > Assume both were built "shared" -- so both had a "libhttpd.dll" shared > > library. However, one is msvcrt.dll based, the other cygwin1.dll based. > > Because the respective httpd.exe's are inherently linked to these > > DLL's, both require that the dirs containing those DLLs are in the > > global system path -- but one of them must come first, since there's > > only one global system path. > > mop, the Win32 native ports of Apache use ApacheCore.dll and > ApacheFooBar.dll name structures for the shared libs. > Yet, if the dll is dependent on cygwin1.dll it must be prefixed with `cyg'. There is not a point of argument, it is an agreed upon standard. Not all packages that existed before the standard was stated have been upgraded to the standard. However, new packages being added must meet that standard, regardless of other points of view. My guess is that you're using a cross build platform that hasn't incorporated the necessary changes to binutils to accomplish this naturally. If this is true then you need to upgrade your binutils cross to the most current versions of cygwin released binutils source. I am not trying to make it harder for you just because I feel like it. I am trying to make it easier for everyone to create, use and port tools in a standard fashion. If we allow exceptions, then it will be harder to determine standard in the future. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [ANN] apache_1.3.22 package available for setup inclusion
Earnie Boyd wrote: > Yet, if the dll is dependent on cygwin1.dll it must be prefixed with > `cyg'. There is not a point of argument, it is an agreed upon > standard. Not all packages that existed before the standard was stated > have been upgraded to the standard. However, new packages being added > must meet that standard, regardless of other points of view. > > My guess is that you're using a cross build platform that hasn't > incorporated the necessary changes to binutils to accomplish this > naturally. If this is true then you need to upgrade your binutils cross > to the most current versions of cygwin released binutils source. I'm confused. What's all this talk about needing "new" binutils? The only feature related to 'cyg' prefixes on dlls is the one I added: --dll-search-prefix. Quoting from the info: `--dll-search-prefix STRING' When linking dynamically to a dll without an import library, search for `.dll' in preference to `lib.dll'. This behavior allows easy distinction between DLLs built for the various "subplatforms": native, cygwin, uwin, pw, etc. For instance, cygwin DLLs typically use `--dll-search-prefix=cyg' This has to do ONLY with the following scenario: 1) I want to build a client program 'bar' 2) it needs to link to the foo DLL 3) I don't have an import lib for foo DLL 4) foo DLL is named according to the subplatform specific scheme: in the case of cygwin, cygfoo.dll 5) I link thus: "gcc Wl,--dll-search-prefix=cyg -L/usr/bin -lfoo -o bar bar.o" (actually, you don't typically need to specify the -Wl,* as I have done -- cygwin's gcc spec file's LINK section will do that for you) --dll-search-prefix affects ONLY the search order for linking TO a DLL. It has no effect on the process of creating or naming a DLL that you try to create. If a given package creates DLLs with the name "libfoo.dll" and you want it to be named "cygfoo.dll", you have to muck with the Makefiles. Period. (Note that import libs should be named libfoo.dll.a, not cygfoo.dll.a or libfoo.a) Or are you talking about some other "feature" of recent binutils of which I am not aware? --Chuck
Re: [ANN] apache_1.3.22 package available for setup inclusion
On Wed, Jan 09, 2002 at 10:44:29AM -0500, Charles Wilson wrote: > However, I don't think it TRULY matters where dlopen'ed DLLs live -- > except that users should not have to add /usr/libexec (or > /usr/lib/perl5/cygwin-multi/auto/ByteLoader/ and > /usr/lib/perl5/cygwin-multi/auto/Data/Dumper/ and ...) to their path. > Also, I do not think that private, dlopened, > not-in-the-public-bin-directory DLLs should be forced to follow the > cyg.dll nomenclature. .dll, lib.dll, whatever. They're > *private* -- who cares what they are named (although .dll is kindof a > necessity due to windows runtime loader and dlopen issues) It actually doesn't matter. But since the default path for libexecdir isn't /usr/libexec but /usr/sbin it should go to /usr/sbin. Or better /usr/lib. Or even better, perhaps, /usr/lib/httpd, /usr/share/httpd, ... > The fact is, many packages put private, non-linkable, > unusable-except-by-themselves shared libs into some private structure. > Like perl does. This is okay, IMO. Sure. > However, packages that do this should not require "external assistance" > to find those dlopen'ed shared libs. Either they should be dlopen'ed > using the full path, or main() should add the requisite directories to > the PATH -- but only for its process space, not globally. Agree. > So, IMO it's fine if apache puts its private, dlopen'ed DLLs into > /usr/libexec/apache/modules or whereever -- but it should not require > that /usr/libexec/apache/modules be added to the global PATH. Except for `libexec', agree. > Now, if apache's httpd.exe is inherently linked to LOTS of mod_*.dll > shared libs -- instead of dlopen'ing them -- then I think that's a poor > design decision and apache needs a bit more work to change that to using > dlopen for the module-related DLL's...otherwise, where's the benefit of > using DLL's? You still need to relink httpd.exe every time you add a > new module...might as well use static libs. Agree. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [ANN] apache_1.3.22 package available for setup inclusion
Earnie, 2002-01-09 21:12:10, du schriebst: > My guess is that you're using a cross build platform that hasn't > incorporated the necessary changes to binutils to accomplish this > naturally. If this is true then you need to upgrade your binutils cross > to the most current versions of cygwin released binutils source. Nope, like with Perl or Python too, Apache is using its own 'wrappers' to build its libs and modules. That has nothing to do with the binutils version. Look here in Apache configuration is defined: SHARED_CORE_EP='lib$(TARGET).ep' SHCORE_IMPLIB='lib$(TARGET).dll' And it is this way also in all the other templates like the Makefile.tmpl files. I patched it today to use a macro instead of the hardcoded prefix and this patch is about 15k big! Anyway, I'm in favour to include it and to submit the patch to the Apache developers because I think it is really stupid to hardcode something like this. I'll look this week to get a similar change into the perl sources so the next perl release will contain a cygperl-5.8.dll;) Gerrit -- begin signature: =^..^= end
Re: [ANN] apache_1.3.22 package available for setup inclusion
Charles Wilson wrote: > > Earnie Boyd wrote: > > > Yet, if the dll is dependent on cygwin1.dll it must be prefixed with > > `cyg'. There is not a point of argument, it is an agreed upon > > standard. Not all packages that existed before the standard was stated > > have been upgraded to the standard. However, new packages being added > > must meet that standard, regardless of other points of view. > > > > My guess is that you're using a cross build platform that hasn't > > incorporated the necessary changes to binutils to accomplish this > > naturally. If this is true then you need to upgrade your binutils cross > > to the most current versions of cygwin released binutils source. > > I'm confused. What's all this talk about needing "new" binutils? Yep, I'd say. My guess is that Stipe is using a cross buiold platform that doesn't include your change. Therefore he has to hard code the prefix in filename translations in the Makefile.in or what ever the configuration files are named. > The > only feature related to 'cyg' prefixes on dlls is the one I added: > --dll-search-prefix. Quoting from the info: > > `--dll-search-prefix STRING' >When linking dynamically to a dll without an import library, search > for `.dll' in preference to `lib.dll'. This > behavior allows easy distinction between DLLs built for the various > "subplatforms": native, cygwin, uwin, pw, etc. For instance, cygwin > DLLs typically use `--dll-search-prefix=cyg' > > This has to do ONLY with the following scenario: > 1) I want to build a client program 'bar' > 2) it needs to link to the foo DLL > 3) I don't have an import lib for foo DLL > 4) foo DLL is named according to the subplatform specific scheme: in > the case of cygwin, cygfoo.dll > 5) I link thus: "gcc Wl,--dll-search-prefix=cyg -L/usr/bin -lfoo -o > bar bar.o" (actually, you don't typically need to specify the -Wl,* as I > have done -- cygwin's gcc spec file's LINK section will do that for you) > > --dll-search-prefix affects ONLY the search order for linking TO a DLL. > It has no effect on the process of creating or naming a DLL that you > try to create. > > If a given package creates DLLs with the name "libfoo.dll" and you want > it to be named "cygfoo.dll", you have to muck with the Makefiles. > Period. (Note that import libs should be named libfoo.dll.a, not > cygfoo.dll.a or libfoo.a) > > Or are you talking about some other "feature" of recent binutils of > which I am not aware? > No, this is the one I'm talking of. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [ANN] apache_1.3.22 package available for setup inclusion
Earnie Boyd wrote: >>> >>I'm confused. What's all this talk about needing "new" binutils? >> > > Yep, I'd say. My guess is that Stipe is using a cross buiold platform > that doesn't include your change. Therefore he has to hard code the > prefix in filename translations in the Makefile.in or what ever the > configuration files are named. No, you're missing my point. You STILL have to hardcode the output filename of the DLL when you are CREATING the dll. Even WITH the "new" binutils. The ONLY time my --dll-search-prefix helps is when you are LINKING to a DLL and you do NOT have the import lib handy. That's all it was created for. When *creating* the DLL, 'gcc -shared' doesn't magically decide to add 'cyg' to the -o filename -- any more than it previously magically added 'lib'. It didn't and it doesn't. My point: he must muck with Makefile.in or whatnot in ANY case -- new binutils or old. Now, if you're talking about the .exe creation phase, when httpd.exe is linked against libhttpd.dll it might not work IF: a) old binutils b) AND dll is named cyghttpd.dll c) AND you don't have an import lib Well, my "fix" for that problem is: during the DLL build phase (since both libhttpd.dll and httpd.exe are both from the same package) generate an import lib and link against that instead. (Because you really shouldn't be linking directly against a DLL anyway except in "emergency" situations -- vitual implibs cannot provide the auto-import fixups, for instance, or static methods (libcygwin.a, libncurses++.dll.a)) --Chuck
Re: ITP: libtool-devel, libtool-stable, libtool (wrappers)
- Original Message -
From: "Christopher Faylor" <[EMAIL PROTECTED]>
> On Wed, Jan 09, 2002 at 01:21:02PM -0500, Charles Wilson wrote:
> >Preliminary versions are here:
> >2) is "rc6" okay for a ${REL} number, or should it be a pure number?
> >(p.s. 'rc' means "robert collins hack" not "release candidate")
>
> upset will do the right thing with it. I just checked. It even seems
to
> properly support rc6 vs. rc7.
>
> I don't have any problems with it but it *is* a departure from the
> guidelines in http://cygwin.com/setup.html, I believe.
>
> I'll let Robert make the executive decision on this one, I think.
I'd prefer a pure number, but if you think folk will get seriously
confused, then I guess rcx is ok.
In general, I'd prefer that 'flavours' get indicated in the package name
(libtool_devel_rc-xxx-x-src.tar.bz2)
Rob
Re: whois package
Hallo Mark, Am 2002-01-09 um 05:24 schriebst du: > Just wanted to drop in a reminder about the whois package. Could I get an > official/unofficial nanny to check it over, or at least a note telling me to > shut up til people have more time? > http://www.networksimplicity.com/whois I tried the executable, it seems to work well. It is stripped now;) The Cygwin specific README is in the source package. Though, I prefer some more specific infos in the README, so it isn't absolutely correct as you stated in the Cygwin README, that you changed nothing than the prefix in the makefile, there is this patch which, applied would put the sources back to their original form. Or isn't the patch part of your port to Cygwin? Usual, or what is used often, is a seperate directory for platform specific files like there is this debian directory, on Cygwin there is often used a seperate directory too, named `CYGWIN-PATCHES'. Gerrit -- =^..^=mailto:[EMAIL PROTECTED]
FW: whois package
It built OOTB. I remove some source for an alternate mkpasswd app the author had included. It wasn't needed for whois functionality. I didn't really consider that patching the app. Other than that, the only modifications that I made were to the Makefile to get things pointing in the right direction. I know the readme isn't that informative, but there just wasn't that much to tell. The author gave no instructions on the usage for whois, so I didn't bother either. The revert patch puts things back together, including the mkpasswd source. It didn't seem like it really applied to whois though, so I didn't mention it in the readme. If that bugs you I'll change it. Again, I didn't change ANY whois source. Oh, now that I think about it I did make one small change to some ancillary perl apps that help during the build process. It was a one-liner that is so trivial I doubt anyone'd care, but kept them from causing problems under some conditions. In any case, they're in the revert patch. Considering the small changes I made, I don't think it'd be necessary to split out another directory for cygwin patches. But, you're the pro. If you still think I should make the changes let me know. Mark > -Original Message- > From: Gerrit P. Haase [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 3:42 AM > To: Mark Bradshaw > Cc: [EMAIL PROTECTED] > Subject: Re: whois package > > > Hallo Mark, > > Am 2002-01-09 um 05:24 schriebst du: > > > Just wanted to drop in a reminder about the whois package. Could I > > get an official/unofficial nanny to check it over, or at > least a note > > telling me to shut up til people have more time? > > > http://www.networksimplicity.com/whois > > I tried the executable, it seems to work well. > It is stripped now;) > > The Cygwin specific README is in the source package. > > Though, I prefer some more specific infos in the README, > so it isn't absolutely correct as you stated in the Cygwin > README, that you changed nothing than the prefix in the > makefile, there is this patch which, applied would put the > sources back to their original form. > > Or isn't the patch part of your port to Cygwin? > > Usual, or what is used often, is a seperate directory for > platform specific files like there is this debian directory, > on Cygwin there is often used a seperate directory too, named > `CYGWIN-PATCHES'. > > > Gerrit > -- > =^..^= > mailto:[EMAIL PROTECTED] >
Re: FW: whois package
On Wed, Jan 09, 2002 at 11:51:20PM -0500, Mark Bradshaw wrote: >From: Mark Bradshaw <[EMAIL PROTECTED]> >To: CA List <[EMAIL PROTECTED]> >Subject: FW: whois package >Date: Wed, 9 Jan 2002 23:51:20 -0500 > >It built OOTB. I remove some source for an alternate mkpasswd app the >author had included. It wasn't needed for whois functionality. I didn't >really consider that patching the app. Other than that, the only >modifications that I made were to the Makefile to get things pointing in the >right direction. > >I know the readme isn't that informative, but there just wasn't that much to >tell. The author gave no instructions on the usage for whois, so I didn't >bother either. > >The revert patch puts things back together, including the mkpasswd source. >It didn't seem like it really applied to whois though, so I didn't mention >it in the readme. If that bugs you I'll change it. Again, I didn't change >ANY whois source. Oh, now that I think about it I did make one small change >to some ancillary perl apps that help during the build process. It was a >one-liner that is so trivial I doubt anyone'd care, but kept them from >causing problems under some conditions. In any case, they're in the revert >patch. > >Considering the small changes I made, I don't think it'd be necessary to >split out another directory for cygwin patches. But, you're the pro. If >you still think I should make the changes let me know. >From your description, it sounds like you made all of the right decisions. I think the package sounds fine as is. cgf
Re: [ANN] apache_1.3.22 package available for setup inclusion
> Actually, -lgdbm SHOULD result in a dynamic link. unless you explicitly > say '-static', ld will first attempt to link against "libgdbm.dll.a" > (the import lib for cyggdbm.dll) BEFORE trying to link against > "libgdbm.a" (the static lib). ??? Should this not be valid only when using libtool?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
=== - Original Message - From: "Stipe Tolj" <[EMAIL PROTECTED]> Cc: "cygwin-apps" <[EMAIL PROTECTED]> Sent: Thursday, January 10, 2002 6:19 PM Subject: Re: [ANN] apache_1.3.22 package available for setup inclusion > > Actually, -lgdbm SHOULD result in a dynamic link. unless you explicitly > > say '-static', ld will first attempt to link against "libgdbm.dll.a" > > (the import lib for cyggdbm.dll) BEFORE trying to link against > > "libgdbm.a" (the static lib). > > ??? > > Should this not be valid only when using libtool?! No. The changes made where against binutils, not libtool. Rob
Re: [ANN] apache_1.3.22 package available for setup inclusion
> Yet, if the dll is dependent on cygwin1.dll it must be prefixed with > `cyg'. There is not a point of argument, it is an agreed upon > standard. Not all packages that existed before the standard was stated > have been upgraded to the standard. However, new packages being added > must meet that standard, regardless of other points of view. Gerrit has suggested a patch for prefixing cyghttpd.dll accordingly. I will incorporate all suggested changes from the list and come back this afternoon with a new apache_1.3.22-2. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
> I patched it today to use a macro instead of the hardcoded prefix and > this patch is about 15k big! > > Anyway, I'm in favour to include it and to submit the patch to the > Apache developers because I think it is really stupid to hardcode > something like this. Gerrit's proposed patches will be revised and forwarded to the Apache guys then. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [ANN] apache_1.3.22 package available for setup inclusion
> Yep, I'd say. My guess is that Stipe is using a cross buiold platform > that doesn't include your change. Therefore he has to hard code the > prefix in filename translations in the Makefile.in or what ever the > configuration files are named. BTW, I'm not using any cross build platform. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
