Re: symlink dll
Max Bowsher schrieb: IT WILL NOT WORK! Try it yourself if you like. Ah sure, static PE imports. So we just have to use delay loading for ld, similar to the MSVC linker. Then via some kind of libcygdelay.a with a symlink resolver before LoadLibrary(). Wine winegcc has it. http://www.mail-archive.com/[EMAIL PROTECTED]/msg20983.html But ld --help | grep delay is empty Still not there? Should be --delay-lib Should not be hard. Objections cgf? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/vcconunderstandinghelperfunction.asp http://www.esat.kuleuven.ac.be/~gcc/shared_libraries.html -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
Problem with setup 2.427 under Windows 2000
Hi all. I am attempting to run setup.exe, version 2.427 under Windows 2000 Professional on a Toshiba laptop. After making all the setup option selections, the setup fails, with a dialog window saying 'setup.exe has been terminated by Windows. You will need to restart the program'. The first time I tried to run setup, I looked in 'setup\var\log'. It said that Cygwin could not detect McShield because McAfee is not installed. I am aware that setup has problems running simultaneously with anti-virus software, but I have no anti-virus software on the computer (as the error diagnostic indicates). This computer is not connected to the internet. So I had to download and burn the tarballs to CD on another machine. I then copied the files from CD to a folder residing on my desktop on the machine in question...and am attempting to run setup from this folder. This is my first time posting to this list and trying to use Cygwin. Many apologies if this has been addressed elsewhere (I've read several postings with regard to 2.427 setup - but none addressing quite the same concern as mine). Best regards, Pat Jones _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: [setup] Why does PackageSpecification haveaprivatecopy-constructor? (Robert?)
On Tue, 2004-08-31 at 23:42 +0100, Max Bowsher wrote: > Unless we add explicit copy-constructors to every single class, I'd rather > just leave it out and let the compiler handle things implicitly? It seems > cleaner to me. I think you'll find every class that has a destructor also has an explicit copy constructor & assignment operator. That class certainly has an explicit assignment operator... being explicit on the copy constructor is consistent. Have you heard of the 'rule of 3' ? Rob signature.asc Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification haveaprivatecopy-constructor? (Robert?)
Robert Collins wrote: On Tue, 2004-08-31 at 14:27 +0100, Max Bowsher wrote: Robert Collins wrote: which is public, and should be usable. See: http://gcc.gnu.org/bugs.html#cxx_rvalbind I agree with you, but the C++ Standard and GCC 3.4 disagree with both of us. Eek. Indeed :-) gcc 3.x have all honoured the privateness of Foo aFoo(Foo());, and whatever warning you are getting is probably correct. As to the privateness of the copy constructor, I didn't comment it, but neither did I implement it: thats an idiom I use, to cause compiler errors when someone tries to do something that they aren't meant to. Why is this something that isn't meant to happen? Because I hadn't written an explicit copy-constructor. You could certainly make it public and implement it if you choose. Do I need to implement it? AFAICS the implicit copy-constructor should be ok - am I wrong? the implicit one will work, but an explicit one would be good practice here IMO. Thats because we have a pointer (_operator) that isn't actually foreign storage, and explicitly copying the pointer, not the contents may make the intent clear. Mmm. I'm not keen on having an explicit constructor doing exactly what the implicit one would do. I thing that would prove quite confusing for any new people trying to understand the code - I know it would be quite puzzling for me, met without context. Also, gcc might do better optimizing away a non-existent constructor than an explicit one - though I don't have any supporting evidence, it seems plausible. Unless we add explicit copy-constructors to every single class, I'd rather just leave it out and let the compiler handle things implicitly? It seems cleaner to me. That's what I'll commit for now, on the premise that removing the private copy-constructor is a step in the right direction, whether we end up with it explicit or implicit. Max.
Re: Compiling Tcl C extension using Cygwin gcc
Wrong list. Redirected. Igor On Tue, 31 Aug 2004, Jingzhao Ou wrote: > Dear all, > > I tried to compile a simple Tcl C extension using Cygwin gcc. I use the > following commands: > > gcc -shared -ltcl -L/lib random.o > > I got the following error messege: > > random.o(.text+0x31):random.c: undefined reference to `_Tcl_WrongNumArgs' > random.o(.text+0x5e):random.c: undefined reference to `_Tcl_GetIntFromObj' > random.o(.text+0x98):random.c: undefined reference to `_Tcl_GetObjResult' > random.o(.text+0xad):random.c: undefined reference to `_Tcl_SetIntObj' > random.o(.text+0xe2):random.c: undefined reference to `_Tcl_PkgRequire' > random.o(.text+0x11a):random.c: undefined reference to `_Tcl_CreateObjCommand' > random.o(.text+0x135):random.c: undefined reference to `_Tcl_PkgProvide' > collect2: ld returned 1 exit status > > I can see that tcl.h is located at /usr/include. Also, libtcl84.a and > libtclstub84.a are located at /lib. > > Can any one kindly help me out? > > Thanks a lot! > > Best regards, > Jingzhao -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw
Compiling Tcl C extension using Cygwin gcc
Dear all, I tried to compile a simple Tcl C extension using Cygwin gcc. I use the following commands: gcc -shared -ltcl -L/lib random.o I got the following error messege: random.o(.text+0x31):random.c: undefined reference to `_Tcl_WrongNumArgs' random.o(.text+0x5e):random.c: undefined reference to `_Tcl_GetIntFromObj' random.o(.text+0x98):random.c: undefined reference to `_Tcl_GetObjResult' random.o(.text+0xad):random.c: undefined reference to `_Tcl_SetIntObj' random.o(.text+0xe2):random.c: undefined reference to `_Tcl_PkgRequire' random.o(.text+0x11a):random.c: undefined reference to `_Tcl_CreateObjCommand' random.o(.text+0x135):random.c: undefined reference to `_Tcl_PkgProvide' collect2: ld returned 1 exit status I can see that tcl.h is located at /usr/include. Also, libtcl84.a and libtclstub84.a are located at /lib. Can any one kindly help me out? Thanks a lot! Best regards, Jingzhao
Re: [ITP] ocaml-3.08.1-1
On Tue, 31 Aug 2004, Corinna Vinschen wrote: > On Aug 31 15:35, Corinna Vinschen wrote: > > On Aug 31 08:53, Christopher Faylor wrote: > > > On Tue, Aug 31, 2004 at 10:41:18AM +0200, Corinna Vinschen wrote: > > > >On Aug 29 17:26, Igor Pechtchanski wrote: > > > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1-src.tar.bz2 > > > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1.tar.bz2 > > > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint (also inline below) > > > > > > > >Uploaded. > > > > > > The setup.hint file which was uploaded was not correct. It contained > > > http errors. I had to re-get it from > > > http://cs1.cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint. > > > > Oops, sorry. > > Urgh, even worse, both archives were broken as well. For some reason > I can't download them using curl. Wget worked, though. I fixed them. Could be a problem with the logging script used on the site. I haven't tested it with curl, only wget and Netscape/Firefox/IE. If curl is what you normally use, I'll install it and make sure that the site works with it for the future. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw
Re: [ITP] ocaml-3.08.1-1
On Aug 31 15:35, Corinna Vinschen wrote: > On Aug 31 08:53, Christopher Faylor wrote: > > On Tue, Aug 31, 2004 at 10:41:18AM +0200, Corinna Vinschen wrote: > > >On Aug 29 17:26, Igor Pechtchanski wrote: > > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1-src.tar.bz2 > > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1.tar.bz2 > > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint (also inline below) > > > > > >Uploaded. > > > > The setup.hint file which was uploaded was not correct. It contained > > http errors. I had to re-get it from > > http://cs1.cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint. > > Oops, sorry. Urgh, even worse, both archives were broken as well. For some reason I can't download them using curl. Wget worked, though. I fixed them. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [setup] Why does PackageSpecification have aprivatecopy-constructor? (Robert?)
On Tue, 2004-08-31 at 14:27 +0100, Max Bowsher wrote: > Robert Collins wrote: > > > > which is public, and should be usable. > > See: http://gcc.gnu.org/bugs.html#cxx_rvalbind > > I agree with you, but the C++ Standard and GCC 3.4 disagree with both of us. Eek. > > gcc 3.x have all honoured the privateness of Foo aFoo(Foo());, and > > whatever warning you are getting is probably correct. > > > > As to the privateness of the copy constructor, I didn't comment it, but > > neither did I implement it: thats an idiom I use, to cause compiler > > errors when someone tries to do something that they aren't meant to. > > Why is this something that isn't meant to happen? Because I hadn't written an explicit copy-constructor. > > You could certainly make it public and implement it if you choose. > > Do I need to implement it? AFAICS the implicit copy-constructor should be > ok - am I wrong? the implicit one will work, but an explicit one would be good practice here IMO. Thats because we have a pointer (_operator) that isn't actually foreign storage, and explicitly copying the pointer, not the contents may make the intent clear. > > However, showing the error you get might be more useful... Thanks. Rob signature.asc Description: This is a digitally signed message part
Re: [ITP] ocaml-3.08.1-1
On Aug 31 08:53, Christopher Faylor wrote: > On Tue, Aug 31, 2004 at 10:41:18AM +0200, Corinna Vinschen wrote: > >On Aug 29 17:26, Igor Pechtchanski wrote: > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1-src.tar.bz2 > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1.tar.bz2 > >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint (also inline below) > > > >Uploaded. > > The setup.hint file which was uploaded was not correct. It contained > http errors. I had to re-get it from > http://cs1.cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint. Oops, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [setup] Why does PackageSpecification have aprivatecopy-constructor? (Robert?)
Robert Collins wrote:
On Tue, 2004-08-31 at 08:54 +0100, Max Bowsher wrote:
So we have code like that at the moment?
Certainly. 4 occurrences in IniDBBuilderPackage.cc and 1 in
package_db.cc.
Eh? I can't find any. We have things like
setSourcePackage(PackageSpecification(name));
Yes, that's what I'm referring to.
which at the end of the call chain does:
_packageversion::setSourcePackageSpecification(PackageSpecification
const &aSpec)
{
_sourcePackage=aSpec;
}
which should not invoke the copy contructor. rather it is the assignment
operator.
PackageSpecification &operator= (PackageSpecification const &);
which is public, and should be usable.
See: http://gcc.gnu.org/bugs.html#cxx_rvalbind
I agree with you, but the C++ Standard and GCC 3.4 disagree with both of us.
gcc 3.x have all honoured the privateness of Foo aFoo(Foo());, and
whatever warning you are getting is probably correct.
As to the privateness of the copy constructor, I didn't comment it, but
neither did I implement it: thats an idiom I use, to cause compiler
errors when someone tries to do something that they aren't meant to.
Why is this something that isn't meant to happen?
You could certainly make it public and implement it if you choose.
Do I need to implement it? AFAICS the implicit copy-constructor should be
ok - am I wrong?
However, showing the error you get might be more useful...
PackageSpecification.h: In member function `virtual void
IniDBBuilderPackage::buildPackage(const String&)':
PackageSpecification.h:70: error:
`PackageSpecification::PackageSpecification(const PackageSpecification&)' is
private
IniDBBuilderPackage.cc:80: error: within this context
80: cp = db.findBinary (PackageSpecification(name));
PackageSpecification.h: In member function `virtual void
IniDBBuilderPackage::buildPackageSource(const String&, const String&)':
PackageSpecification.h:70: error:
`PackageSpecification::PackageSpecification(const PackageSpecification&)' is
private
IniDBBuilderPackage.cc:130: error: within this context
130: csp = db.findSource (PackageSpecification (cbpv.Name()));
PackageSpecification.h:70: error:
`PackageSpecification::PackageSpecification(const PackageSpecification&)' is
private
IniDBBuilderPackage.cc:160: error: within this context
160: cbpv.setSourcePackageSpecification (PackageSpecification
(cspv.Name()));
PackageSpecification.h: In member function `virtual void
IniDBBuilderPackage::buildSourceName(const String&)':
PackageSpecification.h:70: error:
`PackageSpecification::PackageSpecification(const PackageSpecification&)' is
private
IniDBBuilderPackage.cc:375: error: within this context
375: cbpv.setSourcePackageSpecification (PackageSpecification (name));
Re: [ITP] ocaml-3.08.1-1
On Tue, Aug 31, 2004 at 10:41:18AM +0200, Corinna Vinschen wrote: >On Aug 29 17:26, Igor Pechtchanski wrote: >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1-src.tar.bz2 >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1.tar.bz2 >> http://cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint (also inline below) > >Uploaded. The setup.hint file which was uploaded was not correct. It contained http errors. I had to re-get it from http://cs1.cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint. cgf
Re: setup 2.427 runtime error
Igor Pechtchanski wrote: Did you, by chance, use "wget -o"? That would put the headers into the file. FWIW, I just tried this[*] with Firefox 0.9.3 -- no problems. Igor [*] By "this" I mean "download http://cygwin.com/setup-snapshots/setup-2.431.tar.bz2"; No, just Firefox 0.9. Today, for the second time, the Firefox download simply stalled and would not complete. So, Cygwin curl to the rescue -- took about 35 seconds and untarred without a problem. -- David A. Cobb, Software Engineer, Public Access Advocate "By God's Grace, I am a Christian man; by my actions a great sinner." -- The Way of a Pilgrim: R.French, Tr. Life is too short to tolerate crappy software! begin:vcard fn:David A. Cobb n:Cobb;David A. adr:;;7 Lenox Av #1;West Warwick;RI;02893-3918;USA email;internet:[EMAIL PROTECTED] title:Independent Software Consultant note:PGP Key ID#0x4C293929 effective 01/28/2004 x-mozilla-html:TRUE version:2.1 end:vcard
Re: [setup] Why does PackageSpecification have a private copy-constructor? (Robert?)
On Tue, 2004-08-31 at 06:17 -0400, Doctor Bill wrote: > Actually, this makes perfect sense. When you do SomeClass(), without > using the new operator, you are telling the compiler to create this > instance on the stack, and then when you do foo(SomeClass()) you are > telling the compiler to pass this class by value. To do so requires > creating a copy. No. You need to see the method signature to know if this is the case or not. As it happens the signature is void foo(SomeClass const &); > This would not solve your problem. If you are trying to pass the > class by value, a copy will still need to be made. And? there are two separate copy methods for classes: assignment operator and copy constructor. In this case the assignment operator is written and public, and the existing, working code has no copy constructor written. > BTW. I would discourage all of these examples. Why? Because I > firmly believe in using a smart pointer class, and making the actual > constructors private. i.e. These two things are orthogonal. Smart pointers are good, but making the constructors private forces the class to be foreign storage only, which can be an unnecessary burden. ... > If that was followed for all the code, then your original example would have > been written: > > foo.create(Something.create()); eek. Any decent smart pointer class will let you do foo(SomeClass()); Rob signature.asc Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification have a private copy-constructor? (Robert?)
> I can't see why setup's PackageSpecification class has a private
> copy-constructor.
> Am I missing something?
>
> The reason why I am suddenly interested is that the C++ standard says that
> this:
>
> foo(SomeClass())
>
> requires SomeClass's copy-constructor to be accessible (bizarre, no?) and
> g++ 3.4 has decided to enforce this. So, unless I can make the
> copy-constructor public (which I don't want to do if doing so risks other
> problems), I need to rewrite all code like:
Actually, this makes perfect sense. When you do SomeClass(), without
using the new operator, you are telling the compiler to create this
instance on the stack, and then when you do foo(SomeClass()) you are
telling the compiler to pass this class by value. To do so requires
creating a copy.
If foo() only needs temporary access to the instance of SomeClass(),
then you can change foo() to accept a reference operator. Care must
be taken not to store the object passed by reference, because it will
obsolete as soon as the constuctor returns.
On the otherhand, if you want to have perminent access to SomeClass(),
then use the new operator, and change foo to accept a pointer.
foo(new SomeClass());
However, I would discourage this solution, because it is likely to end
with a memory leak, or an object that is deleted twice...
> do_something(PackageSpecification(somename))
>
> to:
>
> PackageSpecification tmppkgspec(somename);
> do_something(tmppkgspec);
This would not solve your problem. If you are trying to pass the
class by value, a copy will still need to be made.
BTW. I would discourage all of these examples. Why? Because I
firmly believe in using a smart pointer class, and making the actual
constructors private. i.e.
class Something
{
private Something() {}
public static SmartPointer create()
{ return new Something(); }
...
}
If that was followed for all the code, then your original example would have
been written:
foo.create(Something.create());
Assuming the SmartPointer template is correctly written, this
eliminates the possibility of memory leaks from unreferenced objects.
Bill
Re: [ITP] ocaml-3.08.1-1
On Aug 29 17:26, Igor Pechtchanski wrote: > http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1-src.tar.bz2 > http://cs.nyu.edu/~pechtcha/cygwin/ocaml/ocaml-3.08.1-1.tar.bz2 > http://cs.nyu.edu/~pechtcha/cygwin/ocaml/setup.hint (also inline below) Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: [setup] Why does PackageSpecification have a privatecopy-constructor? (Robert?)
On Tue, 2004-08-31 at 08:54 +0100, Max Bowsher wrote:
> > So we have code like that at the moment?
>
> Certainly. 4 occurrences in IniDBBuilderPackage.cc and 1 in package_db.cc.
Eh? I can't find any. We have things like
setSourcePackage(PackageSpecification(name));
which at the end of the call chain does:
_packageversion::setSourcePackageSpecification(PackageSpecification
const &aSpec)
{
_sourcePackage=aSpec;
}
which should not invoke the copy contructor. rather it is the assignment
operator.
PackageSpecification &operator= (PackageSpecification const &);
which is public, and should be usable.
gcc 3.x have all honoured the privateness of Foo aFoo(Foo());, and
whatever warning you are getting is probably correct.
As to the privateness of the copy constructor, I didn't comment it, but
neither did I implement it: thats an idiom I use, to cause compiler
errors when someone tries to do something that they aren't meant to.
You could certainly make it public and implement it if you choose.
However, showing the error you get might be more useful...
Rob
signature.asc
Description: This is a digitally signed message part
Re: [setup] Why does PackageSpecification have a privatecopy-constructor? (Robert?)
Robert Collins wrote:
On Mon, 2004-08-30 at 18:33 +0100, Max Bowsher wrote:
I can't see why setup's PackageSpecification class has a private
copy-constructor.
Am I missing something?
erm. to only allow the class itself to create copies.
Yes, but why was it decided to make that restriction? Either I am missing
something, or it is a pointless restriction.
The reason why I am suddenly interested is that the C++ standard says
that
this:
foo(SomeClass())
requires SomeClass's copy-constructor to be accessible (bizarre, no?) and
g++ 3.4 has decided to enforce this.
Even if that is in a method:
SomeClass *
SomeClass::funkyCopy() const
{
SomeClass *result(self);
}
?
Well, obviously in a method of SomeClass, private things of SomeClass are
accessible.
I wasn't able to convert what you mentioned above into a compilable example
(attached is my errorring attempt) - but even if I was, it's a bit deviously
mysterious, and may be entirely unneeded if we can make the copy-constructor
public.
So, unless I can make the
copy-constructor public (which I don't want to do if doing so risks other
problems), I need to rewrite all code like:
do_something(PackageSpecification(somename))
to:
PackageSpecification tmppkgspec(somename);
do_something(tmppkgspec);
which isn't very nice.
So we have code like that at the moment?
Certainly. 4 occurrences in IniDBBuilderPackage.cc and 1 in package_db.cc.
Max.
copycons.cc
Description: Binary data
