Re: gcc -mno-cygwin STL support for setup.exe?
On Sat, Jan 19, 2002 at 03:57:24PM +1100, Danny Smith wrote: >For what its worth, 3.1 libsupc++.a and libstdc++.a build natively with >mingw. (libsupc++.a contains the eh and new/delete stuff that is currently >in libgcc.a for mingw). Locale class support is missing (as it is with >cygwin/newlib), but C-locale works for me. Wide char support is missing, >because of deficiencies in C-runtime. If you want wide char with >-mno-cygwin, you'll need an auxiliary library -- like mingw's [incomplete] >libisocext.a -- to supply C wide char support. Iostreams work for . > In 3.1 -mno-cygwin needs the mingw32/bits headers. Also, there may be >differences in the way the C_runtime functions are promoted into namespace >std. Hmm. I haven't been able to build libstdc++ v3 for cygwin for a while. Maybe it's just a cross build error. cgf
Re: gcc -mno-cygwin STL support for setup.exe?
--- Robert Collins <[EMAIL PROTECTED]> wrote: > > === > - Original Message - > From: "Jason Tishler" <[EMAIL PROTECTED]> > To: "Cygwin-Apps" <[EMAIL PROTECTED]> > Sent: Saturday, January 19, 2002 5:03 AM > Subject: gcc -mno-cygwin STL support for setup.exe? > > > > Unfortunately, I'm getting bogged down trying to add the rebase > > functionality to setup.exe due to the lack of STL. I am hoping that > > I will not have to re-implement linked lists and possibly associated > > arrays too. I see that Rob has a list class, but I don't think that > it > > will meet all of my needs. > > Uhmm, I've not particular objection to STL use. However keeping > setup.exe lean and mean is an objective. We've already added 20% in size > with the reorganisation to date. So I'll ask you to keep an eye on the > stripped .exe size. > > > About a year ago, there was some discussion about adding libstdc++.a > to > > Cygwin's gcc -mno-cygwin mode. Can we revisit this issue? > > I thought it was inked in if you link with g++. > > Rob For what its worth, 3.1 libsupc++.a and libstdc++.a build natively with mingw. (libsupc++.a contains the eh and new/delete stuff that is currently in libgcc.a for mingw). Locale class support is missing (as it is with cygwin/newlib), but C-locale works for me. Wide char support is missing, because of deficiencies in C-runtime. If you want wide char with -mno-cygwin, you'll need an auxiliary library -- like mingw's [incomplete] libisocext.a -- to supply C wide char support. Iostreams work for . In 3.1 -mno-cygwin needs the mingw32/bits headers. Also, there may be differences in the way the C_runtime functions are promoted into namespace std. As far as size, linking in libstdc++.a has a big cost. Some of that will be reduced by getting rid of the extensive tree checking that is currently on by default. Also, the -ffunction-sections, -fdata-sections (now on by default in libstdc++.a builds) don't really seem to add any value, but I haven't played with them yet.. Danny http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own!
Re: mysql server out of the list
Hello Robert, I think Sinisa Milivojevic should be able to explain the details of his reasoning to you. I was forwarding Kaj's response at his own request, including Sinisa's comments (both are from MySQL). - Stephan Robert Collins wrote: > > === > - Original Message - > From: "Stephan Erickson" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, January 19, 2002 12:35 PM > Subject: mysql server out of the list > > > Looks like the MySQL server is not doable due to the way Cygwin > threads > > are implemented, according to the authors.. Only 3 packages then. > > - Stephan > > > > > > > > Kaj Arnö writes: > > > Stephan, > > > > > > As opposed to a number of other products with a Unix background, > MySQL > > > already works well under Windows without any cygwin. Interfacing > MySQL > > > with cygwin is thus not needed; performance would deteriorate, and a > port > > > would likely incur problems with threads. > > > > > > However, the mysql command line interface could be ported to cygwin; > it > > > might even be that this has already been done. > > > > > > Regards, > > > > > > Kaj > > > > > > > Few additional comments to Kaj's excellent message. > > > > Kaj is right on all accounts. And yes, our client has been ported with > > Cygwin, and is a part of every Win32 distro, under the name of > > mysqlc.exe. > > Which, last I heard, still doesn't include the cygwin source, and is in > fact a GPL violation (see the thread I started on the win32-mysql list). > > > Regarding a server, as CygWin does not support properly threads on > > Win32, it is not doable. This is not important, as VC++, which we use > > for building MySQL for Win32, still makes 10% faster code then latest > > CygWin. > > I'm the Cygwin pthreads maintainer, can you specify what you mean by > 'does not support properly threads on win32' ? > > Rob -- Stephan Erickson Mufassa Corporation - http://www.mufassa.com Effortless E-Commerce Solutions for Small Business.
Re: mysql server out of the list
=== - Original Message - From: "Stephan Erickson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 19, 2002 12:35 PM Subject: mysql server out of the list > Looks like the MySQL server is not doable due to the way Cygwin threads > are implemented, according to the authors.. Only 3 packages then. > - Stephan > > > > Kaj Arnö writes: > > Stephan, > > > > As opposed to a number of other products with a Unix background, MySQL > > already works well under Windows without any cygwin. Interfacing MySQL > > with cygwin is thus not needed; performance would deteriorate, and a port > > would likely incur problems with threads. > > > > However, the mysql command line interface could be ported to cygwin; it > > might even be that this has already been done. > > > > Regards, > > > > Kaj > > > > Few additional comments to Kaj's excellent message. > > Kaj is right on all accounts. And yes, our client has been ported with > Cygwin, and is a part of every Win32 distro, under the name of > mysqlc.exe. Which, last I heard, still doesn't include the cygwin source, and is in fact a GPL violation (see the thread I started on the win32-mysql list). > Regarding a server, as CygWin does not support properly threads on > Win32, it is not doable. This is not important, as VC++, which we use > for building MySQL for Win32, still makes 10% faster code then latest > CygWin. I'm the Cygwin pthreads maintainer, can you specify what you mean by 'does not support properly threads on win32' ? Rob
Re: mysql server out of the list
On Fri, Jan 18, 2002 at 05:35:09PM -0800, Stephan Erickson wrote: >Looks like the MySQL server is not doable due to the way Cygwin threads >are implemented, according to the authors.. Only 3 packages then. I think a few more details about the cygwin thread issues would be appreciated. cgf
mysql server out of the list
Looks like the MySQL server is not doable due to the way Cygwin threads are implemented, according to the authors.. Only 3 packages then. - Stephan Kaj Arnö writes: > Stephan, > > As opposed to a number of other products with a Unix background, MySQL > already works well under Windows without any cygwin. Interfacing MySQL > with cygwin is thus not needed; performance would deteriorate, and a port > would likely incur problems with threads. > > However, the mysql command line interface could be ported to cygwin; it > might even be that this has already been done. > > Regards, > > Kaj > Few additional comments to Kaj's excellent message. Kaj is right on all accounts. And yes, our client has been ported with Cygwin, and is a part of every Win32 distro, under the name of mysqlc.exe. Our GUI client, mysqlgui is built on Win32 only with CygWin. Regarding a server, as CygWin does not support properly threads on Win32, it is not doable. This is not important, as VC++, which we use for building MySQL for Win32, still makes 10% faster code then latest CygWin. -- Regards, __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus <___/ www.mysql.com -- Stephan Erickson Mufassa Corporation - http://www.mufassa.com Effortless E-Commerce Solutions for Small Business.
Volunteer to maintain links, the text mode web browser
Greetings. I'd like to volunteer to maintain the Cygwin package for 'links', a text mode web browser. This is my first Cygwin package so please be gentle with me :) # This is setup.hint for links-0.96-1 sdesc: "Text mode web browser" ldesc: "Links is a very capable text-mode web browser. It obeys keyboard commands similar to lynx but unlike lynx, links supports the HTML TABLE tag. Links also allows you to download files in the background." category: Web requires: cygwin openssl The packages are available from http://koti.welho.com/stikka2/cygwin/links/links-0.96-1.tar.bz2 http://koti.welho.com/stikka2/cygwin/links/links-0.96-1-src.tar.bz2 and http://koti.welho.com/stikka2/cygwin/links/setup.hint -- Sami Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/ /* No comment */
Re: gcc -mno-cygwin STL support for setup.exe?
On Sat, Jan 19, 2002 at 09:59:03AM +1100, Robert Collins wrote: >>We have a looming problem here, though, since we will need to include >>at least a libsupc++.a for -mno-cygwin if/when we start using gcc 3.x. >>I can't build setup.exe with newer versions of gcc currently due to >>this lack. I don't know if libstdc++.a even builds under mingw >>currently. > >I presume you mean mingw with gcc 3? I mean libstdc++ (v3). cgf
Re: gcc -mno-cygwin STL support for setup.exe?
=== - Original Message - From: "Jason Tishler" <[EMAIL PROTECTED]> To: "Cygwin-Apps" <[EMAIL PROTECTED]> Sent: Saturday, January 19, 2002 5:03 AM Subject: gcc -mno-cygwin STL support for setup.exe? > Unfortunately, I'm getting bogged down trying to add the rebase > functionality to setup.exe due to the lack of STL. I am hoping that > I will not have to re-implement linked lists and possibly associated > arrays too. I see that Rob has a list class, but I don't think that it > will meet all of my needs. Uhmm, I've not particular objection to STL use. However keeping setup.exe lean and mean is an objective. We've already added 20% in size with the reorganisation to date. So I'll ask you to keep an eye on the stripped .exe size. > About a year ago, there was some discussion about adding libstdc++.a to > Cygwin's gcc -mno-cygwin mode. Can we revisit this issue? I thought it was inked in if you link with g++. Rob
Re: gcc -mno-cygwin STL support for setup.exe?
=== - Original Message - From: "Christopher Faylor" <[EMAIL PROTECTED]> > Weren't you going to rewrite rebase in C? It is very likely that it wouldn't > be accepted into binutils otherwise. > >About a year ago, there was some discussion about adding libstdc++.a to > >Cygwin's gcc -mno-cygwin mode. Can we revisit this issue? > > The biggest issue with relying on libstdc++.a for for setup.exe is that it > requires this library to be built for cross-compilation. I have no idea how > to do that. > > We have a looming problem here, though, since we will need to include at > least a libsupc++.a for -mno-cygwin if/when we start using gcc 3.x. I can't > build setup.exe with newer versions of gcc currently due to this lack. > I don't know if libstdc++.a even builds under mingw currently. I presume you mean mingw with gcc 3? This could well be a serious issue as we use new() currently. I hate to suggest it, but maybe having a contributed cross-compile package really is the way to go. Sure, it'll massively increase build-cross-compile-from-scratch overhead (build cygwin target, build mingw target, build cygwin hosted) I suspect that we'll need a mingw target cross compiler to generate the correct threading model for libstc++ at a minimum. Rob
Re: gcc -mno-cygwin STL support for setup.exe?
On Fri, Jan 18, 2002 at 01:59:57PM -0500, Jason Tishler wrote: >> The biggest issue with relying on libstdc++.a for for setup.exe is that it >> requires this library to be built for cross-compilation. I have no idea how >> to do that. > >I don't know either -- this is why I'm asking for help. I think that was clear. What I'm trying to say is that it may not be possible to use functions from libstdc++.a. In gcc 3.x, this will include things like new() and delete(). cgf
Re: gcc -mno-cygwin STL support for setup.exe?
On Fri, Jan 18, 2002 at 07:50:20PM +0100, Jan Nieuwenhuizen wrote: >Christopher Faylor <[EMAIL PROTECTED]> writes: > >> The biggest issue with relying on libstdc++.a for for setup.exe is that it >> requires this library to be built for cross-compilation. I have no idea how >> to do that. > >What am I missing? Hard to say. -mno-cygwin? gcc 3.x? cgf
Re: gcc -mno-cygwin STL support for setup.exe?
Chris, On Fri, Jan 18, 2002 at 01:06:32PM -0500, Christopher Faylor wrote: > On Fri, Jan 18, 2002 at 01:03:05PM -0500, Jason Tishler wrote: > >Unfortunately, I'm getting bogged down trying to add the rebase > >functionality to setup.exe due to the lack of STL. I am hoping that > >I will not have to re-implement linked lists and possibly associated > >arrays too. I see that Rob has a list class, but I don't think that it > >will meet all of my needs. > > Weren't you going to rewrite rebase in C? It is very likely that it > wouldn't be accepted into binutils otherwise. Yes, I'm done converting the stand-alone version into C. I have even converted it into a Mingw program so that it can rebase the Cygwin DLL too. Sorry for not being clear. What I'm trying to accomplish now is to integrate something like the following functionality directly into setup.exe: On Sat, Dec 08, 2001 at 01:39:52PM +1100, Robert Collins wrote: > Actually what I have in mind is > [snip] > * changes to setup > if (installing a .dll or .exe) > rebase and store info in /etc/setup > > rebase: > find object size - sz > lookup a gap of sz in the address table in /etc/setup > find object dependencies > foreach > if (a cygwin .dll) > rebase this > if (a non-cygwin .dll) > store the base and size info in /etc/setup The rebase stuff above is easy -- unfortunately, the address table stuff without STL (i.e., list, map, etc.) is not. :,( > >About a year ago, there was some discussion about adding libstdc++.a to > >Cygwin's gcc -mno-cygwin mode. Can we revisit this issue? > > The biggest issue with relying on libstdc++.a for for setup.exe is that it > requires this library to be built for cross-compilation. I have no idea how > to do that. I don't know either -- this is why I'm asking for help. Thanks, Jason
Re: gcc -mno-cygwin STL support for setup.exe?
Christopher Faylor <[EMAIL PROTECTED]> writes:
> The biggest issue with relying on libstdc++.a for for setup.exe is that it
> requires this library to be built for cross-compilation. I have no idea how
> to do that.
What am I missing?
19:37:40 fred@appel:~$ locate libstdc++.a | grep x-
/home/cygwin/cygwin-1.3.3/linux-x-cygwin/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libstdc++.a
/home/cygwin/cygwin-1.3.3/linux-x-cygwin/usr/lib/libstdc++.a.2.10.0
/home/cygwin/cygwin-1.3.6/linux-x-cygwin/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/libstdc++.a
/home/cygwin/cygwin-1.3.6/linux-x-cygwin/usr/lib/libstdc++.a.2.10.0
This x-compiles fine here
#include
#include
int
main ()
{
string s = "Hello world";
cout << s << endl;
return 0;
}
Greetings,
Jan.
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
gcc -mno-cygwin STL support for setup.exe?
Unfortunately, I'm getting bogged down trying to add the rebase functionality to setup.exe due to the lack of STL. I am hoping that I will not have to re-implement linked lists and possibly associated arrays too. I see that Rob has a list class, but I don't think that it will meet all of my needs. About a year ago, there was some discussion about adding libstdc++.a to Cygwin's gcc -mno-cygwin mode. Can we revisit this issue? Thanks, Jason
Re: apache-1.3.22-4 no-detach patch
On Fri, Jan 18, 2002 at 10:35:23AM +0100, Stipe Tolj wrote: > Corinna Vinschen wrote: > > > > On Fri, Jan 18, 2002 at 12:35:13AM +0100, Stipe Tolj wrote: > > > Corinna, > > > > > > could you please apply the attached patch against the last 1.3.22-3 > > > source tree. This will turn detaching of the parent process off. > > > Please try if this makes cygrunsrv happy. > > > > Didn't you test it? Anyway, I don't have the source tree. I'd > > appreciate if you could give me a pointer to a binary archive. > > I did test it if it stays attached and if the service itself is > operational. I wanted to let you do the cygrunsrv magic, it's your > thing I guess. I'm testing running under cygrunsrv if you send me a pointer to the binary. I'm not going to build apache by myself. > > Hmm, I'd vote for a command line option... '-n' for `nodetach' or so? > > -n is used for the Win32 native port as you pointed out. I'm not sure > what the Apache officials think about this. They may claim that this > may lead to confusion. Anyway, if we decide to have a flag, I would > appritiate it if it is OS-wide, that means any UNIX platform may use > it to run with no-detach. I have posted a RFC for this on the Apache > developers list. That's probably the better approach. Unfortunately the `-D' is already used. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: libtool-devel and kde2 - problem with AC_PROG_CXX
Sorry, I have send this to the wrong list.
RE: libtool-devel and kde2 - problem with AC_PROG_CXX
> > Ralf Habacker wrote: > > > Robert Collins wrote: > > > > > >>Quoting from the fink site (it was handy): > >>"The current development branch: This is the development version that > >>will some day be released as libtool 1.5. It has resulted from the merge > >>of 1.4 and the MLB. It supports C, C++ and Java (via gcj). > >>Unfortunately, it can't be easily told apart from 1.4, you'll have to > >>check the version number inside ltmain.sh." > >> > >>For the _last time_, the devel libtool DOES NOT and WILL NOT create > >>ltconfig. Don't expect it, because its NOT MEANT TO create it. > >> > > > > It does not create ltconfig, but it need it as you could see in my last mail > > > As of 20010531, there seem to have been a few remaining references to > ltconfig -- within the _LT_AC_LANG_CXX and _LT_AC_LANG_GCJ m4 macros. > Not surprising that those were missed -- C++/java don't have nearly the > history that C does. Studying the ChangeLogs, ltconfig was removed on > 2000-09-19, but "stale references" were continually being found and > fixed thru 2001 (2001-04-05, 2001-04-24). > Aha > >>checking if libtool supports shared libraries... yes > >>checking how to run the C++ preprocessor... g++ -E > >>admin/ltconfig: Can't open admin/ltconfig: No such file or directory > >>configure: error: libtool tag configuration failed > >> > > > > I have searched in the libtool cvs on subversions.gnu.org and seen that on > 20010531 the merge > > of the mlb code wasn't ready. You can verify this by unpacking the recent > > libtool-devel-20010531-6.tar.bz2 and looking in the libtool.m4 if there are >references to > > ltconfig. > > > Not entirely correct. As I said, it seems that the _CXX and _GCJ > references hadn't been removed as of 20010531. However, the MLB merge > was -- if not complete, then at least partially begun: > > 2001-05-27: ltmain.in: Merged from multi-language-branch > 2001-05-27: libtool.m4: Merged from multi-language-branch > 2001-05-30: libtool.m4: Merged ltconfig.in from multi-language-branch > ^^ not a typo > > However, as you say, there were some ADDITIONAL merges from MLB that > happened later: on 2001-06-24. > > > > If you follow the below mentioned link you can see that the tag creation support >was > > completed at 2001 Jun 24 , so the libtool from 20010531 can't contain full tag >creation > > support. > > > [snip] > > > > I have appended a patched libtool.m4 from the libtool cvs HEAD release numver >1.245 and > > patched mostly of the changes Charles provided in the rc5 diffs and got a > working CXX/GCJ/RC > > tag creating. Try it. It may not be complete for all cases, but I think you are >able to > > verify this. > > > Actually, I am not able to guarantee that >1) taking the Robert's patches to libtool.m4(20010531) >2) applying those changes to libtool.m4(20011128) >3) but NOT updating any of the other interdependent files that form > the libtool toolset > > results in a stable libtool. You have said that it works well for you > on a given set of dlls -- but you've already demonstrated that your case > is rather special: multi-language, CXX/GCJ, etc. I don't want to fix > the corner case by breaking the mainline cases: single language, C. I understand > Look, Ralf, this libtool port is a work in progress. Right now, I'd > like for folks to test the "normal" stuff. (So far, that looks good). > Then, we need to port forward ALL of the patches to ALL of the files -- > not just libtool.m4 -- to current HEAD cvs libtool. > Okay that make sense > Gary Vaughan (the libtool maintainer) is on the case, he WANTS to put > this stuff into current cvs. He was waiting for Robert's FSF copyright > assignment to go thru before he started : and that just happened last > week (see the libtool mailing list...) I have seen this on the libtool list > Be patient -- it was hard enough getting the infrastructure in place to > have an auto-import capable libtool become part of the cygwin dist in > the first place. I couldn't very well pester Gary to accept the patches > until we had a working example installation...and that just happened > last week. I have not problem with this > Just to review the tool-side things that have been happening in the past > six months (not all me, but I *have* been pushing most of them) >test Paul Sokolovsky's auto-import stuff >push it into official binutils > >migrate (old) autoconf package to autoconf-stable >create autoconf-devel package (and talk very very fast to get corinna > to support it) >create autoconf (wrappers) > >migrate (old) automake package to automake-stable >create automake-devel package (and talk very very fast...) >create automake (wrappers) > >>> special automake hack to make the split-install ALSO search > /usr/share/aclocal in addition to /usr/autotool/*/share/aclocal <<< > >create libtool-stable (1.4.2) >create libtool-devel package from Robert's patches (but based on a
Re: apache-1.3.22-4 no-detach patch
Corinna Vinschen wrote: > > On Fri, Jan 18, 2002 at 12:35:13AM +0100, Stipe Tolj wrote: > > Corinna, > > > > could you please apply the attached patch against the last 1.3.22-3 > > source tree. This will turn detaching of the parent process off. > > Please try if this makes cygrunsrv happy. > > Didn't you test it? Anyway, I don't have the source tree. I'd > appreciate if you could give me a pointer to a binary archive. I did test it if it stays attached and if the service itself is operational. I wanted to let you do the cygrunsrv magic, it's your thing I guess. The apache-1.3.22-3 source tree is available from the location I announced and the -4 patch applies to it. the /usr/doc/Cygwin readme describes the configure flags to be used. It's pretty forward and builds in <= 3 min. > > I haven't included any extra starting flag. In this case apache does > > not detach by default for Cygwin. Any objections from the others? > > Hmm, I'd vote for a command line option... '-n' for `nodetach' or so? -n is used for the Win32 native port as you pointed out. I'm not sure what the Apache officials think about this. They may claim that this may lead to confusion. Anyway, if we decide to have a flag, I would appritiate it if it is OS-wide, that means any UNIX platform may use it to run with no-detach. I have posted a RFC for this on the Apache developers list. 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: apache-1.3.22-4 no-detach patch
On Fri, Jan 18, 2002 at 12:35:13AM +0100, Stipe Tolj wrote: > Corinna, > > could you please apply the attached patch against the last 1.3.22-3 > source tree. This will turn detaching of the parent process off. > Please try if this makes cygrunsrv happy. Didn't you test it? Anyway, I don't have the source tree. I'd appreciate if you could give me a pointer to a binary archive. > I haven't included any extra starting flag. In this case apache does > not detach by default for Cygwin. Any objections from the others? Hmm, I'd vote for a command line option... '-n' for `nodetach' or so? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
