setup.exe problem [johnm@falch.net: Re: no exec files from gcc and c++]
---BeginMessage--- Jean-Marc Nuzillard wrote: g++ -c hello.cpp - g++ not found, took some time to think to try c++ I think at least this part of your problems is due to another bug in setup.exe 2.194.2.15. (I've looked briefly for relevant discussion here and on cygwin-apps and seen none -- sorry if this is already known.) According to http://www.cygwin.com/packages/, the gcc package contains 72192 2001-06-17 22:02:45 usr/bin/c++.exe 35328 2001-06-17 22:02:45 usr/bin/c++filt.exe 72704 2001-06-17 22:02:45 usr/bin/cpp.exe 0 2001-06-17 22:02:45 usr/bin/g++.exe link to usr/bin/c++.exe If you look in setup.log.full I suspect you'll see that extraction of g++.exe failed. I suspect current setup.exe is not dealing with links in tarball packages correctly. One of my users alerted me to this problem in my prc-tools package today. Files listed as link to [previous file in tarball] were not being extracted by setup.exe 2.194.2.15, and would be absent from the resulting installation. OTOH setup.exe 2.125.2.10 given the same tarball extracted them correctly. John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ---End Message---
Re: release setup now?
Michael's script works for me. One caveat: I had to manually run 'clean_lst.pl ./a*.lst' 26 times (using different starting letters). However, that was because I got a BSOD when running it fullbore -- where it tried to fixup all files. Now, a perl script should never ever be able to cause a BSOD on W2K. Neither should a user-mode program (like setup.exe) However, on my machines, both do on rare occasions. The error is down deep in ntoskrnl and/or the ntfs file system driver -- I even did a full reinstall of the OS, yet I still get the BSOD sometimes. It's an MS bug, I am sure -- and I've noticed that it only happens when there are a lot of files being opened and closed rapidly. (For instance, when uninstalling lots of files in an old package, and installing lots of files in the new replacement package. Or when opening each .lst and rewriting them without \000 chars.) So, I don't blame Michael's script for my BSOD. I blame MS. But, once I limited the number of open/modified files per run (by running the script by hand on each letter of the alphabet) Michael's script DID successfully remove the \000 chars. --Chuck Robert Collins wrote: I'd already done a reinstall... can someone here validate Michael's script? (someone that tried the beta and has not reinstall those packages..) Rob
Now that the new setup is here...
there were two things I was going to do: 1) move gettext from the contrib directory to the latest directory -- and see if anybody barfs. 2) update bzip2 to the latest release -- which involves the grand library split thing (bzip2 - bzip2 + libbz2_0). However, the name libbz2_0 is incompatible with the old setup, and even 'cygcheck -c' gets confused prior to the cygwin-1.3.8 release. So, once I release libbz2_0, there's no going back to the old setup -- and everybody MUST update to the new setup or their installation will become very confused. Are we confident enough in the current setup.exe to do this? I ask because we've already yanked it down ONCE --Chuck
RE: setup.exe problem [johnm@falch.net: Re: no exec files from gcc and c++]
Sigh. Well I'm nearly back on deck. (Long story). I'll look into this today, I hope. Rob -Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 3:54 AM To: [EMAIL PROTECTED] Subject: setup.exe problem [[EMAIL PROTECTED]: Re: no exec files from gcc and c++]
RE: Now that the new setup is here...
Holdoff please Chuck, cgf's forwarded post here indicates that there is still at least one serious bug in 2.194... Rob -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 8:03 AM To: [EMAIL PROTECTED] Subject: Now that the new setup is here... there were two things I was going to do: 1) move gettext from the contrib directory to the latest directory -- and see if anybody barfs. 2) update bzip2 to the latest release -- which involves the grand library split thing (bzip2 - bzip2 + libbz2_0). However, the name libbz2_0 is incompatible with the old setup, and even 'cygcheck -c' gets confused prior to the cygwin-1.3.8 release. So, once I release libbz2_0, there's no going back to the old setup -- and everybody MUST update to the new setup or their installation will become very confused. Are we confident enough in the current setup.exe to do this? I ask because we've already yanked it down ONCE --Chuck
RE: prev/curr/test
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 23, 2002 5:19 PM To: [EMAIL PROTECTED] Subject: prev/curr/test I think I've seen the light. ... I think that Robert is right that if you click on test you should only get packages that have test versions. Ditto for prev. Ditto for curr. Woohoo! There are no skip, keep, reinstall, or source options. Just install and uninstall. If you want to install source, you select the install action and click on source. If you only want the source and bin is checked, uncheck bin. This won't cause an uninstall. It will only cause bin not to be installed. Hmm. I think that unclicking bin should uninstall - leaving it there would be counter-intuititive. We could use colors in the Bin field to indicate things like installed due to dependency (blue) or uncheck me at your peril (red). I'm red-green colour insensitive, which isn't quite colour blind, but heading in that direction. If we do colour to indicate things, we should only do it is a backup strategy - there should be some other primary indicator. I think this would simplify things a lot and maybe cut down on use confusion. Actually, we could even get rid of the individual actions and add another button on the top to flip between the install and uninstall views. How about: prev ( ) curr (.) test (.) PackageBinSource Description bash 2.05a [X][ ] Blah, blah fileutils 4.1-1[ ][X] Blah, blah make 3.79.1-5 [x][ ] Blah, blah Tick Bin to install foo. Untick Bin to remove foo. Tick Source to trigger a download of the source (download only mode) or extraction (install from x mode). I think it's a good idea to have multiple interfaces - that's why 90% of the coding effort I've been putting in has been aimed at separating out the UI and the engine, to allow fast changes like this. I can have the above layout in place in about 30 minutes, if you want to see it. However, I think some folk will want the current interface, so perhaps we offer a 'basic' and 'advanced' download of setup, or a [Advanced] button somewhere on the chooser. (To start with I'd suggest two downloads because the chooser doesn't use a factory yet, so I can't parameterize the display at runtime. That is a goal though.) Rob
Re: Keeping base, adding standard.
On Tue, Mar 26, 2002 at 09:11:45AM +1100, Robert Collins wrote: I just meant that I am extremely unlikely to agree with you on this one. So, I won't be willing to let setup grow in this direction. I would not blame you if you felt that your creativity was being hampered. If the decision is made, and it's not going to alter, and you are not willing to talk through it, then I might feel somewhat unhappy. However that is unlike you, so I'll not prejudge the situation. Sniff. You're right. Nevermind on this point, then. I took up the mantle expecting to serve the community that has provided me with many things - this is something I can offer back... so I don't expect to control whats offered with iron fists. I do expect to control the how and when of the implementation though. Maybe a way to resolve this is for there to be a testing version of setup.exe where we can experiment with different user interfaces or methods of doing things. We could even put a link to the testing version of setup.exe on the cygwin web site. I encourage anyone who wants to experiment with code that needs some revisions to get 'just-so' to create a branch using the cvs* scripts in the winsup/maint dir. Simply cd to cinstall, and create your branch from there, using a name like cgf_newui. It'll create a new dir with the branch info, you'll need to either update to the tag in your current dir, or switch the directories around. FWIW I have cinstall symlinked, and a number of directories with different tags, so I can switch very easily. I'm actually in the position of being a pretty normal cygwin user right now. No time, just amazingly good ideas. I'll try to generate the appropriate resentment if no one acts on my ideas in the next day or so. cgf
RE: prev/curr/test
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 11:21 AM Hmm. I think that unclicking bin should uninstall - leaving it there would be counter-intuititive. If you have the word install next to a box, I don't think it follows that it will be uninstalled. Of course, my turn for stupidity :} Tick Bin to install foo. Untick Bin to remove foo. Tick Source to trigger a download of the source (download only mode) or extraction (install from x mode). And when you just don't want a package? What do you click to get the equivalent of skip? Don't click either? In this example perhaps the bin column should be labelled install. Given your above comments, I think we still need another clickable thing next to the Bin/Source, unless you have some way of getting the equivalent of a skip/keep. Ahh, so if you don't want to update you can stay put. Hmm. What about [X] - install [H] - hold [ ] - uninstall I know, it's heading back to the circular clicking thing :[. However, I think some folk will want the current interface, so perhaps we offer a 'basic' and 'advanced' download of setup, or a [Advanced] button somewhere on the chooser. (To start with I'd suggest two downloads because the chooser doesn't use a factory yet, so I can't parameterize the display at runtime. That is a goal though.) I don't see any gain in keeping the old interface if we make the above changes. There is equivalent functionality and, imo, better clarity. You always get into trouble when you start trying to maintain disparate views. Actually there is less functionality - no one-step reinstall, no selection of arbitrary versions. Currently I can install any version found on my hard disk, these proposed interfaces remove that ability. I haven't looked into the code recently, but I think this gets rid of some of that state machine stuff that (used to?) was never quite right. I think that nuking that logic would be a big enough goal for going to a plan like this. It would remove the need for the state machine code, but that is very stable now anyway (see package_meta if you are interested). Rob
RE: Keeping base, adding standard.
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 11:25 AM I'm actually in the position of being a pretty normal cygwin user right now. No time, just amazingly good ideas. I'll try to generate the appropriate resentment if no one acts on my ideas in the next day or so. Oh... well I guess it's time for: * patchs appreciated. * You know, *you* could help. * it's a volunteer project! * And *who* is going to do this? * ... :] Rob
Re: Keeping base, adding standard.
On Tue, Mar 26, 2002 at 11:33:16AM +1100, Robert Collins wrote: I'm actually in the position of being a pretty normal cygwin user right now. No time, just amazingly good ideas. I'll try to generate the appropriate resentment if no one acts on my ideas in the next day or so. Oh... well I guess it's time for: * patchs appreciated. * You know, *you* could help. * it's a volunteer project! * And *who* is going to do this? * ... Hey, aren't you *paid* to work on this stuff??? It seems to *me* that... Uh. Lost my train of thought. cgf
Re: prev/curr/test
On Tue, Mar 26, 2002 at 11:31:22AM +1100, Robert Collins wrote: Tick Bin to install foo. Untick Bin to remove foo. Tick Source to trigger a download of the source (download only mode) or extraction (install from x mode). And when you just don't want a package? What do you click to get the equivalent of skip? Don't click either? In this example perhaps the bin column should be labelled install. But, if I make a mistake, my ability to correct it is somewhat hampered unless we tri-state the box. (Hey I verbed something) Given your above comments, I think we still need another clickable thing next to the Bin/Source, unless you have some way of getting the equivalent of a skip/keep. Ahh, so if you don't want to update you can stay put. Hmm. What about [X] - install [H] - hold [ ] - uninstall I know, it's heading back to the circular clicking thing :[. Yeah. However, I think some folk will want the current interface, so perhaps we offer a 'basic' and 'advanced' download of setup, or a [Advanced] button somewhere on the chooser. (To start with I'd suggest two downloads because the chooser doesn't use a factory yet, so I can't parameterize the display at runtime. That is a goal though.) I don't see any gain in keeping the old interface if we make the above changes. There is equivalent functionality and, imo, better clarity. You always get into trouble when you start trying to maintain disparate views. Actually there is less functionality - no one-step reinstall, no selection of arbitrary versions. Currently I can install any version found on my hard disk, these proposed interfaces remove that ability. How does it remove that? Click on the install next to a package name (All in this case). I haven't looked into the code recently, but I think this gets rid of some of that state machine stuff that (used to?) was never quite right. I think that nuking that logic would be a big enough goal for going to a plan like this. It would remove the need for the state machine code, but that is very stable now anyway (see package_meta if you are interested). It wasn't all *that* unstable when I left it (except for the auto uninstall thing which people are still reporting, apparently). I just think the idea of states is needlessly complicated. cgf
Re: prev/curr/test
On Mon, Mar 25, 2002 at 08:02:17PM -0500, Brian Keener wrote: Christopher Faylor wrote: evil and should be abolished. The only way to get old versions should be at a macro level. You click a button and get all of the old stuff, you click another button and get all of the current stuff, you click another button to get all of the test stuff. I think that Robert is right that if you click on test you should only get packages that have test versions. Ditto for prev. Ditto for curr. Sorry guys, I still like the idea of keeping Prev,Curr and Test but as a means of limiting the maximum version I want to see - IE if I didn't select Test I won't see any test but I will see prev and Current. Then I suggest we do away with the Source Box and nix the idea of a bin box and simply use the clickable version and within the version we have such entities as the following (assume the version installed is 1.4.3 and there is a current of 1.4.4 and I have curr selected on the radio buttons): I really think that cycling behavior of the current setup is a major source of confusion for most people. keep/skip (obviously skip if nothing were installed), uninstall (would only exist if package installed), 1.4.4 binsrc, 1.4.4 bin, 1.4.4 src, reinstall binsrc (would reinstall both for 1.4.3), reinstall bin (reinstall bin for 1.4.3), reinstall src (reinstall src for 1.4.3), retrieve binsrc (retrieves installed bin and src), retrieve bin (retrieves installed bin), retrieve src (retrieves installed src), retrieve 1.4.4 binsrc ... Sorry, but I really don't like this. Adding a whole bunch of new things for a user to cycle through (or even select from a pulldown) is moving in the wrong direction, IMO. cgf
RE: prev/curr/test
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 12:02 PM To: [EMAIL PROTECTED] Subject: Re: prev/curr/test And when you just don't want a package? What do you click to get the equivalent of skip? Don't click either? In this example perhaps the bin column should be labelled install. But, if I make a mistake, my ability to correct it is somewhat hampered unless we tri-state the box. so don't make mistakes ? :}. Ahh, so if you don't want to update you can stay put. Hmm. What about [X] - install [H] - hold [ ] - uninstall I know, it's heading back to the circular clicking thing :[. Yeah. Or we could do a radio button triplet - Binary Install Hold (don't change at all) Uninstall (or skip if not installed) = (*)()() How does it remove that? Click on the install next to a package name (All in this case). I must be confused. I thought that of the layout: prev/curr/test bin src package version [] [] description ... that only the bin and src and prev/curr/test would be clickable. Categories wouldn't change, but they don't allow specific version selection anyway. Are you suggesting that version be clickable as well? In which case I don't see how it's different from what we have today (barring the removal of reinstall). It would remove the need for the state machine code, but that is very stable now anyway (see package_meta if you are interested). It wasn't all *that* unstable when I left it (except for the auto uninstall thing which people are still reporting, apparently). I just think the idea of states is needlessly complicated. Which is why it got removed :}. My phrase above 'state machine code' was actually inaccurate - I should have said 'version selection code'. There isn't any state machine per se anymore, simply a collection of versions, and bin/src selection. Rob
Re: prev/curr/test
Christopher Faylor wrote: Sorry, but I really don't like this. Adding a whole bunch of new things for a user to cycle through (or even select from a pulldown) is moving in the wrong direction, IMO. But a big deal at one point in time was the ability to get to packages/versions that were in the local directory and install those - how else can you do this if you limit your self to prev, curr, and test. What if the current setup.ini has a prev version and a current version but I still have the one prior to the prev version and it was right the two most recent are wrong and I want to roll back to it - How do I do this under you folks way of thinking. I like the simpler approach for sure but let my option I select tell me everything - don't give me 4 different buttons and umpteen combinations to choose from to get where I want to be - talk about confusing. Just my thoughts and .02 worth.
Re: prev/curr/test
Um. Could you guys stop Cc'ing me, please. I don't know how my name got on the Cc list but please remove it. I set the Reply-To for a reason. cgf
Re: prev/curr/test
On Mon, Mar 25, 2002 at 08:27:04PM -0500, Brian Keener wrote: Christopher Faylor wrote: Sorry, but I really don't like this. Adding a whole bunch of new things for a user to cycle through (or even select from a pulldown) is moving in the wrong direction, IMO. But a big deal at one point in time was the ability to get to packages/versions that were in the local directory and install those - how else can you do this if you limit your self to prev, curr, and test. I don't know who this was a big deal for. It isn't for me; especially if we would be confusing the people who want to use setup.exe for its normal use at the expense of people who have additional requirements. I think the whole cycling through versions thing was a big mistake. I don't know of any other setup utility that allows this kind of thing. Heck, I believe that you actually need to specify a different repository entirely if you want to install non-current packages in debian. Is this correct, Robert? What if the current setup.ini has a prev version and a current version but I still have the one prior to the prev version and it was right the two most recent are wrong and I want to roll back to it - How do I do this under you folks way of thinking. You don't. You find some other method for reverting to software that is 1 revision old. This is not a hardship. AFAIK, setup has never allowed you to do more than prev/curr/test. I like the simpler approach for sure but let my option I select tell me everything - don't give me 4 different buttons and umpteen combinations to choose from to get where I want to be - talk about confusing. And how do you know when you've hit the current version? You see it scroll by and remember that you want 1.4.9-1 bin and then click the mouse ten more times to get back to that. That's really not user friendly, IMO. cgf
Re: more package
requires: ash cygwin libintl1 ncurses pcre almost nothing actually depends on the ncurses package. the dependency is probably on the libncurses6 and/or terminfo packages. Thanks. I actually edited a copy of grep's .hint, FYI. grep doesn't have an ncurses dependency. Yes, I added that one for 'more'. Other than that the deps for 'grep' are the same. Sorry, I couldn't remember at the time which one I added, even though that's the only logical one. Are you really linking with the perl version of regex, btw? Yep. 'more' had some old BSD-style regex stuff that I needed to change and I used pcre mostly because 'man pcre' gave me all the info I needed. So I guess this is really an improved version since it'll take perl regex expressions. OK so here is a new setup.hint: sdesc: a primitive pager ldesc: Classic version of the basic pager, from the util-linux sources. This package is mainly for compatibility with older scripts (and users :). The 'less' package contains a much more full-featured pager, including the ability to move backward in a file. test: more-2.11o-1.tar.bz2 category: Base requires: ash cygwin libintl1 pcre termcap __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
Re: Invisible X client window borders
not much help from me but I had the same problem with TWM myself, no border when resizing. I think I had border when I was moving but I am not sure it was a while ago. I downloaded and compiled Blackbox and the problem doesn't show up under that. - Original Message - From: Dwight Schauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 25, 2002 2:26 PM Subject: Invisible X client window borders I'm not sure if this is an Xserver problem or a a window manager on. In TWM and in Afterstep I don't get the rectangle or grid when moving or resizing client windows. The proper window decoration does show up on the x clients. I have an Nvidia GeForce II MX and Windows XP. (On an Athlon Thunderbird). I installed the latest Cygwin and Xfree a few days ago. I'm running AfterStep v. 1.8.11 compiled and running under Cygwin/XFree. I did the same at work a week ago on a different machine, and resizing, placing, and moving windows is fine. (I don't have window contents shown on resize or move, and I use manual window placement if there is no room to display the window). At work on Cygwin/XFree the grid/rectangle shows up correctly in Afterstep, as it does on a native Linux XFree86 server. Apart from that, XFree and Afterstep seem to be running fine on Cygwin. I can't get aterm to work, (it compiles and run and can get as far as displaying the shell prompt, but then it locks up) so I'm using the cygwin provided rxvt instead and it runs fine under X.
Re: missing telnet, solution
This whole thread got me thinking about possible ways to avoid this xxx is missing problem... I thought that I'd throw an idea out for discussion... Would it make sense to have setup install a dummy script for some of the common utilities and then overwrite that script with the actual utility if it is selected from the gui as it should be? Assume that the missing utility is called ttt.exe Have setup create /bin/missing and link ttt.exe to missing ln -s /bin/missing /bin/telnet.exe stuckymb [547] ls -l missing ttt.exe -rwxr-xr-x1 stuckymb mygroup 214 Mar 25 18:00 missing lrwxrwxrwx1 stuckymb mygroup94 Mar 25 17:58 ttt.exe - missing stuckymb [548] stuckymb [548] stuckymb [548] stuckymb [548] cat missing #!/bin/sh echo If you are seeing this message, it means that the echo echo$0 echo echo 'still needs to be selected from within setup' echo echo 'Please re-run setup' echo stuckymb [549] stuckymb [549] stuckymb [549] stuckymb [549] ttt.exe If you are seeing this message, it means that the ./ttt.exe still needs to be selected from within setup Please re-run setup When setup is re-run to download the actual ttt.exe the dummy ttt.exe could be deleted and then replaced with the correct executable. Just my 0.02 cents worth... --Mark - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 23, 2002 9:46 PM Subject: Re: missing telnet, solution On Sat, Mar 23, 2002 at 06:18:05PM +0100, Palic, Darko wrote: Hello Christopher, okay it is nice to follow the request of the users, but why isn't a selectbox available, there something like basic/minimal, common/typical and complete could be selected instead of changing the whole setup? It would help! What answer are you expecting? It's a volunteer project. We make changes as time permits and as people are inclined. We thought the current setup with categories would be an improvement and apparently it wasn't. It never occurred to us that people wouldn't be able to figure out that you could click on things and see packages to install. But, that was the case. Once it became clear that there was a problem and that people didn't like having to select things individually, I would have liked to see an immediate resolution of the problem but it just didn't happen. It's not like I can fire anyone for not improving setup for you. I'm just damn grateful that Robert and others are spending time working on it at all. Anyway, the new, just released, version of setup has some improvements for selecting whole categories. That should make things much easier. We're discussing other alternatives all of the time but the basic problem is that we have a lot of people who just ask aggrieved questions like the above or who repeat the same observations that have been made countless times before, and very few people who are actually willing to help make things better. If you want to contribute (and apparently you do), then setup.exe discussions are happening in the cygwin-apps mailing lists. If you have further questions, you should (after reviewing the mail archives there) send them there. cgf I think the change you're referring to was that we added, at the request of many users, a minimal install. It's based on the debian base category, which does not include bzip2. The default installation is a really basic one and it's looking like we need to change that. Anyway, I'll try to keep in this in mind if we change something in the future that impacts Cygwin/XFree86. It never occurred to me that this would be an issue.
RE: missing telnet, solution
-Original Message- From: mstucky5 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 10:10 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: missing telnet, solution This whole thread got me thinking about possible ways to avoid this xxx is missing problem... I thought that I'd throw an idea out for discussion... Would it make sense to have setup install a dummy script for some of the common utilities and then overwrite that script with the actual utility if it is selected from the gui as it should be? In debian, there is a package that will do this - I think it that when a binary is not found it queries dpkg to see if a package that can provide it exists. Anyway, I think that an _automated_ approach to this could be quite useful, but not a manual one. (I realise that you didn't imply either, I'm simply getting there first :}). Rob
X connection to 127....broken
Hi, I am assuming this is the list for config troubleshooting. Here is my prob. I just dl and installed cygwin and xfree today but I can't get it to run though. The sceen just pops up for about a second and then it vanishes. The startxwin window says: X connection to 127.0.0.1:0.0 broken (explicit kill or server shutdown) The log file says this: ddxProcessArgument () - Initializing default screens winInitializeDefaultScreens () - w 800 h 600 ddxProcessArgument () - screen - argc: 5 i: 1 When I try to run XWin, it gives an error message: A required .DLL file, CYGWIN1,DLL was not found. I got all my stuff from: http://archive.progeny.com/cygwin/xfree/binaries/4.2.0/ TIA Ed __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
X connection to 127.0. ...explicit kill...
Hi, I'm assuming this is the list for config problems. I dl the prog today from: http://archive.progeny.com/cygwin/xfree/binaries/4.2.0/ When I run it, the x window pops up for maybe a second and then vanishes and the startxwin shell says: X connection to 127.0.0.1:0 broken (explicit kill or server shudown) If I try to run XWin.exe, it says that it cant find cygwin1.dll. TIA The log file says: ddxProcessArgument () - Initializing default screens winInitializeDefaultScreens () - w 800 h 600 ddxProcessArgument () - screen - argc: 5 i: 1 __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
Exiting xfree
One problem I have when I run xfree in Windows mode (which I prefer), is that sometimes I accidentally hit the exit button in the upper right hand corner of the my Cygwin/Xfree window. This sometimes causes me to loose work. I know that a way of avoiding this is to use the fullscreen flag with XWin.exe. However, I prefer to run in a window, so my question is whether there is a way to disable the windows exit button so that the only way to exit is with Alt-F4? (Using the nowinkill flag doesn't help here.) Thanks, Lars. -- Lars Jensen, TMCC/Vista B200, 7000 Dandini Blvd, Reno NV 89512-3999. Internet: [EMAIL PROTECTED], http://www.scsr.nevada.edu/~jensen Tel: 775.673.7113 FAX: 775.674.7592
[ANNOUNCEMENT] Updated: libtool-devel-20020316-1
The 'libtool-devel' package has been updated to 20020316-1 It contains a (slightly) hacked version of libtool (from CVS 16-Mar-2002), installed into /usr/autotool/devel/*. Most of our earlier changes have been absorbed into the official libtool CVS. See the NOTES at the end of this email for some additional information. -- Chuck Wilson To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'libtool-devel' from the 'Devel' category. You may need to click the Full button if it doesn't show up. Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection. In Japan, ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ is already updated. In DK, http://mirrors.sunsite.dk/cygwin/ is usually up-to-date. If one of the above doesn't have the latest version of this package you can either wait for the site to be updated or find another mirror. Please send questions or comments to the Cygwin mailing list at: [EMAIL PROTECTED] . If you want to subscribe go to: http://cygwin.com/lists.html I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] NOTES: 1) libtool (along with autoconf and automake) are really only for developer use. If you don't already have a good understanding of how to use the tools -- and experience using them on a normal unix platform -- then you probably DON'T want to learn with this port. The combination of a) the brain dead DLL format (compared to elf shared libs) b) still evolving shared lib support in the binutils/gcc/cygwin c) the VERY beta status of libtool-devel d) the wacky -stable/-devel/wrapper structure we are forced to use means that cygwin is NOT a good platform to learn how to use the autotools. PLEASE do not ask for tutorials on automake/autoconf/libtool use on the cygwin mailing list -- you will either be ignored, or mocked. 2) ALL libtools since version 1.4 (May 2001) have dispensed with ltconfig.sh. So, when re-libtoolizing, be sure to delete ltconfig.sh first. 3) You can't pick and choose. If you want to use libtool-devel, you must also use automake-devel and autoconf-devel. Likewise, all of the -stable versions must be used together. 4) libtool-devel installs its info files and man pages into /usr/* as well as into /usr/autotool/devel/*. Also, libtool-devel's cygltdl-3.dll is installed into /usr/bin. Therefore, applications dynamically linked to that DLL by libtool-stable and by libtool-devel will both use libtool-devel's version at runtime. (Fortunately, this is okay -- libtool-devel's cygltdl-3.dll works fine with apps that expect libtool-stable's version). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime
This is from the glibc documentation (is glibc meaningless to the Cygwin project?): Function: int gettimeofday (struct timeval *tp, struct timezone *tzp) The gettimeofday function returns the current calendar time as the elapsed time since the epoch in the struct timeval structure indicated by tp. (see section 21.2 Elapsed Time for a description of struct timespec). Information about the time zone is returned in the structure pointed at tzp. If the tzp argument is a null pointer, time zone information is ignored. The return value is 0 on success and -1 on failure. The following errno error condition is defined for this function: ENOSYS The operating system does not support getting time zone information, and tzp is not a null pointer. The GNU operating system does not support using struct timezone to represent time zone information; that is an obsolete feature of 4.3 BSD. Instead, use the facilities described in 21.4.8 Functions and Variables for Time Zones. I do not understand you quite clearly. And I want to emphasize again that IT USED TO WORK! Do I need to write patches so that the code is unpatched? Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- On Mon, Mar 25, 2002 at 10:45:09AM +0800, Wu Yongwei wrote: Thank you for your response, and I do see some reasonableness in your message. However, I can hardly calm down unless someone can answer: 1) Why should Cygwin break both backward compatibility with older versions and compatibility Linux? Basic meanness. 2) If ftime does not need to get timezone information, how about gettimeofday? Look again. I quoted the Single Unix Specification for both gettimeofday and ftime. I did not read the documentation you quoted (where is it?), but no documentation I read about gettimeofday states that it should ignore the timezone argument. http://www.opengroup.org/onlinepubs/7908799/index.html My program used to run on both Cygwin and Linux. But now I even do not know how to make it behave like before except that I try to find an old version of Cygwin and revert to it. Or I could use some ugly macros to define _timezone as timezone in some cases and use _timezone: Cygwin recognizes _timezone as a valid global variable while Linux recognizes only timezone. Anybody enlightens me to show me the right way to go? Or should I abandon running international time-related program on Cygwin in a cross-platform way? You could always submit a patch. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
New SETUP.EXE
Dear all, I have installed the new setup 2.125.2.10 and I am installing new binaries from one of the mirror sites. What I notice is that when I install from the internet setup creates a new directory on my windows file system. In that new directory setup stores the setup.ini and the contrib plus latest directories. The directory name now is called ftp%3a%2fmirrors.rcn.net%2fmirrors ... while the contrib and latest directory were created in the local package directory itselve. Is setup now going to install from this new directory or is it not going to find the binaries. What is different between the new approach and the one from a few weeks ago. What can I do to get it working again as before. When I use different mirror sites what result will this have on my installation? regards, Danny -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime
Also notes the usage of unspecified. Unspecified means the standard does not say anything about the implementation, and, IMHO, the implementors are free to choose the best practices. I think it is obviously a good way to follow BSD. Am I wrong? Best regards, Wu Yongwei --- Original Message from Christopher Faylor --- int gettimeofday(struct timeval *tp, void *tzp); DESCRIPTION The gettimeofday() function obtains the current time, expressed as seconds and microseconds since 00:00 Coordinated Universal Time (UTC), January 1, 1970, and stores it in the timeval structure pointed to by tp. The resolution of the system clock is unspecified. If tzp is not a null pointer, the behaviour is unspecified. int ftime(struct timeb *tp); DESCRIPTION The ftime() function sets the time and millitm members of the timeb structure pointed to by tp to contain the seconds and milliseconds portions, respectively, of the current time in seconds since 00:00:00 UTC (Coordinated Universal Time), January 1, 1970. The contents of the timezone and dstflag members of tp after a call to ftime() are unspecified. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin1.dll bug in ftime
Also notes the usage of unspecified. Unspecified means the standard does not say anything about the implementation, and, IMHO, the implementors are free to choose the best practices. ... or to not implement anything at all. I think it is obviously a good way to follow BSD. Possibly. The better way for application developers is to follow the Single UNIX Specification. Any application relying on results that are explicitely marked as unspecified in the SUS standard can be considered non-portable. From the SUSv3 documentation: APPLICATION USAGE For applications portability, the time() function should be used to determine the current time instead of ftime(). Karsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Time sharing and fork
-Original Message- From: Stephane Corbe [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 4:55 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Time sharing and fork Christopher Faylor wrote: That's not guaranteed fork behavior. If the child never started, that would be a bug. As you can see in my previous post, the programm is really simple : a loop of printf for the child, a loop of printf for the father. There's no place for a bug here ... And there's no bug either in the result you got :-) There is no guaranteed behavior with respect to which process is scheduled after a fork on windows or linux. If you want to serialize things use one of the wait calls. I don't want serialized anything, I don't expect that the child or the father start at first. So what is your problem? Just I wish that the child share the time (the cpu) with his father. Except that if the child (or the father) uses all available processor time, then as long as it runs there is no time to left to the father. What an OS tries to do here is to give you th emost effective result, that is the shorter total execution time. It would switch only if it thinks it's beneficial, i.e. for example if there is contention of the output, that is if you write on a low speed output device: the chile write some, get blocked, then the father start, the output drains during startup time (it's probably handled in interruption), then th efather can output some before being blocked, then the son restarts, etc. etc. ad nauseam :-) On solaris the two processes run like that : (A is some printf from father, B is some printf from child) ABABABABABABA(end of A)B(end of B) On cygwin I have this result : AAA(end of A)BBB(end of B) Both are perfectly fitting the requirements written by your program: you want some number of As *and* some number of Bs and do not give *any* constraint regarding th eorder in which you want the As and Bs to get out. If you *need* some constraints then you have to use synchronization primitives... HTH Bernard Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin/DJGPP and memory
Dear all, I'm browsing the mailing list archive about the limits on memory allocation under cygwin, but I've not yet a complete picture. What is the real limit when I use new[] in a C++ program? The one I set in windows2000 register heap_chunk_in_mb? What are the differences in memory limits between cygwin and DJGPP, besides the DJGPP need for DPMI? Please clarify this point for a medium level programmer as me. I am migrating from DJGPP to cygwin to benefit from a non-dos GCC interface, but I need to work with large sparse matrices and my programs are greedy for memory! Thanks a lot for you time. Regards Giovanni -- Dr. Giovanni Spagnuolo, Ph.D. Assistant Professor University of Salerno Dipartimento di Ingegneria dell'Informazione ed Ingegneria Elettrica (D.I.I.I.E.) Via Ponte Don Melillo 84084 Fisciano - Salerno - Italy phone: +39 089 964258 fax: +39 089 964218 e-mail: [EMAIL PROTECTED] You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions. Naguib Mahfouz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New version of setup.exe broken when running with WINE
I resent this due to a small problem with the spam filters. Thanks for your support. --- Sylvain Petreolle [EMAIL PROTECTED] a écrit : Date: Fri, 22 Mar 2002 18:43:19 +0100 (CET) --- Hi all, Thanks for the analogy with the toaster :). Seriously, Trying to run cygwin under WINE environment is a good testcase for both power companies (ie cygwin and wine :)). The goal of a bug entry created for wine is to run bash/sh in WINE environment. If someone is interested you can look at http://bugs.codeweavers.com/show_bug.cgi?id=443 Various cygwin programs function at this day (mount,ls, and several others). Thanks by advance, Sylvain. repliers : Please cc me in replies. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.3.10 gcc/g77 won't install, won't work
Recently I updated cygwin to 1.3.10 and got installation incomplete Check /setup.log.full message. but no /setup.log.full was found. Later I discovered that g77(v0.5.25) won't produce .exe files while producing .o files. This was the same with gcc(v2.95.3-5). The same versions of gcc and g77 work nicely on solaris7-sparc environment. Still later found that when reinstalling cygwin package gcc always appears on the update list as an item to be 'Skip'ped, and would show installation incomplete... message when setup has finished. I saw down the mailing list archive a posting that previous setup program(v2.125.2.10) would install gcc properly when installing from local hard disk, after downloading .bz2 files with current setup program(v2.194.1.15). But trying haphazrdly to reinstall gcc several times I have already deleted the previous version of setup program. I tried also to download the .bz2 file and bzip2 -c -d ...bz2 | tar xvf - on the bash/cygwin environment. But the extracted gcc/g77 won't work either. -- ¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬ Ryu Myungsunn, Organic EL Group +82-2-526-4498 LG Elite ¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: crypt command
I looked at it. The crypt that comes with cygwin appears to do something different than [I, Sanjay] expected, at least on at least Sanjay's system and mine. Output from crypt seems to stop at 14 bytes: bash-2.05a$ man apropos out bash-2.05a$ crypt mypass out encryptedout bash-2.05a$ ls -la total 22 drwxrwxrwx2 1303 513 0 Mar 25 08:42 . drwxrwxrwx 78 Administ 544 20480 Mar 21 11:18 .. -rw-rw-rw-1 campbe_r Domain U 14 Mar 25 08:42 encryptedout -rwxrwxrwx1 Administ Domain U 533 Mar 25 08:42 out bash-2.05a$ cat out | crypt mypass encryptedout bash-2.05a$ ls -la total 22 drwxrwxrwx2 1303 513 0 Mar 25 08:42 . drwxrwxrwx 78 Administ 544 20480 Mar 21 11:18 .. -rw-rw-rw-1 campbe_r Domain U 14 Mar 25 08:42 encryptedout -rwxrwxrwx1 Administ Domain U 533 Mar 25 08:42 out bash-2.05a$ This is a very suspicious size, since after looking at the crypt code that is the size of the retkey array: (encrypt.c, line 253). static char retkey[14]; After looking further, I see that encrypt.c's crypt function, which returns the ultimate printed out values, returns the retkey array only. I further notice that crypt does not read any stdin input. I conclude that this crypt is designed to only print out a key for a given salt/password. Am I correct? If so, what is this utility generally used for? To Sanjay - it looks like compiling mcrypt would be your best bet, as it has a backwards compatibility mode with older crypt(1)s. http://mcrypt.hellug.gr/ -Richard Campbell -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.3.10 gcc/g77 won't install, won't work
On Monday 25 March 2002 06:06, Ryu Myungsunn wrote: Recently I updated cygwin to 1.3.10 and got installation incomplete Check /setup.log.full message. but no /setup.log.full was found. Later I discovered that g77(v0.5.25) won't produce .exe files while producing .o files. This was the same with gcc(v2.95.3-5). The same versions of gcc and g77 work nicely on solaris7-sparc environment. Your font is quite difficult to read here. It's not your g77 version. You may have somehow introduced breakage (possibly in more than one place) in your g77 linkage setup. Since you give no particulars, anyone trying to help you would be guessing. You haven't even revealed whether you got binutils installed. One of the common problems with the cygwin setup is the introduction of a spurious -lm in the default g77 setup. Such breakage in the g77 version installed by cygwin does not necessarily extend to a separate version of gcc/g77 installed from source. -- Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Networking problem
At 01:02 AM 3/25/2002, Rajaraman B wrote: Hi, There is no support for IP_HDRINCL socket option. Many header files Check out Winsock capabilities in this area. Cygwin's socket support is dependent on Winsock functionality. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/DJGPP and memory
At 08:54 AM 3/25/2002, G.Spagnuolo wrote: Dear all, I'm browsing the mailing list archive about the limits on memory allocation under cygwin, but I've not yet a complete picture. What is the real limit when I use new[] in a C++ program? The one I set in windows2000 register heap_chunk_in_mb? Yep! Assuming, of course, that you have that much total memory (physical + swap) space available for use. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Setup.exe update
On Monday 25 Mar 02, Cliff Hones writes: Despite having followed the various posts, I am still confused by the current status of setup.exe, and I doubt if I'm alone. Robert announced the new version on 19th March. I downloaded setup.exe shortly after (but didn't use it) and found I had got version 2.194.2.15. After a flurry of mails about -luser32 and problems with mountpoints and w32api, cgf announced on 21st March that setup.exe was being reverted until the problem was fixed. I just tried downloading setup.exe again and found I still got 2.194.2.15. We figured out how to work around the missing -luser32 problem by repacking a couple of packages. So it was no longer necessary to have pulled the latest setup. So it's back. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/DJGPP and memory
Thanks for your reply. So, the total memory is the only limit. I'm reading about a mysterious 256MB limit of cygwin: what about it? With respect to DJGPP, by cygwin I am able to use the virtual memory. Is this true? Thanks again gs At 09.48 25/03/2002 -0500, you wrote: At 08:54 AM 3/25/2002, G.Spagnuolo wrote: Dear all, I'm browsing the mailing list archive about the limits on memory allocation under cygwin, but I've not yet a complete picture. What is the real limit when I use new[] in a C++ program? The one I set in windows2000 register heap_chunk_in_mb? Yep! Assuming, of course, that you have that much total memory (physical + swap) space available for use. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Dr. Giovanni Spagnuolo, Ph.D. Assistant Professor University of Salerno Dipartimento di Ingegneria dell'Informazione ed Ingegneria Elettrica (D.I.I.I.E.) Via Ponte Don Melillo 84084 Fisciano - Salerno - Italy phone: +39 089 964258 fax: +39 089 964218 e-mail: [EMAIL PROTECTED] You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions. Naguib Mahfouz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Setup.exe update
Dear David, I earlier posted a mail of setup creating new menu entries in my install directory. I have looked at the setup version that was being used and found, just downloaded it today, version: 2.194.2.15, while I was under the impression using an other version. Can somebody elaborate on which version we currently are? regards, Danny -Original Message- From: David Starks-Browning [mailto:[EMAIL PROTECTED]] Sent: maandag 25 maart 2002 15:51 To: Cliff Hones Cc: [EMAIL PROTECTED]; Cliff Hones (E-mail) Subject: Re: [ANNOUNCEMENT] Setup.exe update On Monday 25 Mar 02, Cliff Hones writes: Despite having followed the various posts, I am still confused by the current status of setup.exe, and I doubt if I'm alone. Robert announced the new version on 19th March. I downloaded setup.exe shortly after (but didn't use it) and found I had got version 2.194.2.15. After a flurry of mails about -luser32 and problems with mountpoints and w32api, cgf announced on 21st March that setup.exe was being reverted until the problem was fixed. I just tried downloading setup.exe again and found I still got 2.194.2.15. We figured out how to work around the missing -luser32 problem by repacking a couple of packages. So it was no longer necessary to have pulled the latest setup. So it's back. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: crypt command
On Mon, 25 Mar 2002 09:22:28 -0500 you wrote: I looked at it. The crypt that comes with cygwin appears to do something different than [I, Sanjay] expected, at least on at least Sanjay's system and mine. [snip] I conclude that this crypt is designed to only print out a key for a given salt/password. Am I correct? yes If so, what is this utility generally used for? It is generally used for creating the one-way crypt of a password used in unix /etc/passwd files or Apache on Unix authentication files. The cygwin version also allows the passing of a salt. Both the password and the salt must be passed on the command line and not on stdin, the resulting crypt is available on stdout. Its very easy to knock your self up a crypt. Perl has a crypt function so it should be very easy to create a crypt that takes the plain text password on stdin. It would also very easy to do in 'C' (although it appears that mcrypt will do the job). -- Mark Himsley In Acton -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Networking problem
Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] writes: Check out Winsock capabilities in this area. Cygwin's socket support is dependent on Winsock functionality. If you want to be able to send and receive raw ethernet frames, your best be is to take a look at WinPcap. (Use Google; I don't have the exact URL in my head). -- /Jesper -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Shared libraries.
Hello, I'm trying to build and use shared libraries with Cygwin under Windows 2000. The first step, i.e. building the library, succeeds. I get a libmylib.so (together with libmylib.so.1 and limmylib.so.1.0.0). However, linking is a problem. I've written a small program which uses libmylib.so and try to link it as follows: g++ -o testprogram.exe testprogram.o -L/usr/src/DynLib -lmylib This results in the error: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cannot find -lmylib For information the entire output when executing make clean: rm -f PrintTest.o PrintTest.exe.exe PrintTest.d *~ make make[1]: Entering directory `/usr/src/dynlibtest' g++ -M -Wall PrintTest.cpp PrintTest.d g++ -M -Wall PrintTest.cpp | sed s/\\.o/.d/ PrintTest.d make[1]: Leaving directory `/usr/src/dynlibtest' make[1]: Entering directory `/usr/src/dynlibtest' g++ -Wall-c -o PrintTest.o PrintTest.cpp g++ -o PrintTest.exe PrintTest.o -L/usr/src/DynLib -lmylib /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cannot find -lmylib collect2: ld returned 1 exit status make[1]: *** [PrintTest.exe] Error 1 make[1]: Leaving directory `/usr/src/dynlibtest' make: *** [clean] Error 2 When using: g++ -o PrintTest.exe PrintTest.o libmylib.so I get the error: collect2: ld terminated with signal 11 [Segmentation fault] Can someone tell me what I'm doing wrong? Kind regards, Wiebe de Vries. Pecoma * ICT-professionals * http://www.pecoma.nl Is deze e-mail niet voor u bedoeld? Laat het ons even weten. Bij voorbaat dank. Dit e-mailbericht is gecontroleerd op computervirussen met MIMEsweeper. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Setup.exe update
On Monday 25 Mar 02, Gaethofs, Danny writes: Dear David, I earlier posted a mail of setup creating new menu entries in my install directory. I have looked at the setup version that was being used and found, just downloaded it today, version: 2.194.2.15, while I was under the impression using an other version. (huh?) Can somebody elaborate on which version we currently are? Can't you just download http://cygwin.com/setup.exe and run it? It should tell you what version it is. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Setup.exe update
aha, Current version downloaded is 2.194.2.15. A few days (19 march 2002) before we still had 2.125.2.10. Danny -Original Message- From: David Starks-Browning [mailto:[EMAIL PROTECTED]] Sent: maandag 25 maart 2002 16:14 To: Gaethofs, Danny Cc: [EMAIL PROTECTED] Subject: RE: [ANNOUNCEMENT] Setup.exe update On Monday 25 Mar 02, Gaethofs, Danny writes: Dear David, I earlier posted a mail of setup creating new menu entries in my install directory. I have looked at the setup version that was being used and found, just downloaded it today, version: 2.194.2.15, while I was under the impression using an other version. (huh?) Can somebody elaborate on which version we currently are? Can't you just download http://cygwin.com/setup.exe and run it? It should tell you what version it is. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Your (Our) Problem
I am having a similar problem to what you describe, and I think it is the same as a thread from earlier in the weekend about gcc and perl etc. not installing. On my home machine, I tried many times to get gcc to install from the new setup (install over the internet anyway). Each time I got the same incomplete installation message. The log file by the way, at least for me, was down in my regular Cygwin directories. I did not see anything in there of the nature of this did not work. Each time I would try again to install, gcc would be marked as skip. There would be no uninstall option either, just skip or install. One additional point. When I would perform gcc -v, it would pull up my secondary install of gcc-3.0.4, and doing which g++ yields the version in /usr/local/bin, which is again, the gcc-3.0.4. It may be that having the secondary install of gcc is causing a problem for the new version of setup. In which case the problem is not the fault of setup, but mine. There did appear to be an unofficial looking consensus on a thread this weekend that some of the problems in this area could be fixed by downloading the distribution to the local drive, then using an older version of setup to do the install. I have not tried this. Wayne Keen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Programs fail to recognize paths.
While trying to use cvs on cygwin (Windows XP) the command cvs -d /usr/local/cvs-repository update returns the error directory /usr/local/cvs-repostory does not exist. ls has no problem finding the directory and it is possible to cd to the directory. Thought this might be due to installing the cvs binary so downloaded and build/installed cvs from souce in cygwin. No improvement. While using gvim (started from a cygwin command prompt) if there is a Windows directory c:\cygwin\usr\wx2 that has been mounted as /usr/wx2, gvim can see the directory but cannot see the files in it or subdirectories of it. If one first cd's to the /usr/wx2 then gvim can see all files in the directory. Any help understanding and correcting these problems would be greatly appreciated. Thank you. -- Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Recreating gcc package
Hi Could someone provide me with information on how to recreate the gcc package? I could not find any information in /usr/doc/gcc or in the gcc source tarball. Thanks a lot Lars Munch -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: no exec files from gcc and c++
Jean-Marc Nuzillard wrote: g++ -c hello.cpp - g++ not found, took some time to think to try c++ I think at least this part of your problems is due to another bug in setup.exe 2.194.2.15. (I've looked briefly for relevant discussion here and on cygwin-apps and seen none -- sorry if this is already known.) According to http://www.cygwin.com/packages/, the gcc package contains 72192 2001-06-17 22:02:45 usr/bin/c++.exe 35328 2001-06-17 22:02:45 usr/bin/c++filt.exe 72704 2001-06-17 22:02:45 usr/bin/cpp.exe 0 2001-06-17 22:02:45 usr/bin/g++.exe link to usr/bin/c++.exe If you look in setup.log.full I suspect you'll see that extraction of g++.exe failed. I suspect current setup.exe is not dealing with links in tarball packages correctly. One of my users alerted me to this problem in my prc-tools package today. Files listed as link to [previous file in tarball] were not being extracted by setup.exe 2.194.2.15, and would be absent from the resulting installation. OTOH setup.exe 2.125.2.10 given the same tarball extracted them correctly. John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
sed problem with procmail
I have procmail reciepes such as the following:
:0
* !^From:.*domain1.com
* !^From:.*domain2.com
{
# Fall through
}
:0 E
| formail -rf -I X-Mailer: AD Spam Canceller \
-i Subject: Your mail is suspected of being SPAM and has been filtered! (24)
| \
cat - $SPAMREPLY | sendmail -t
Where domain1 and domain2 are domains that I filter out totally. $SPAMREPLY is
defined to
point to a file and sendmail is setup to be exim.
Now the filtering works except I see the following in my procmail log:
From userdomain1.com Sun Mar 24 13:21:35 2002
Subject: NO OTHER Spy/Security CD Like THIS
Folder: formail -rf -I X-Mailer: AD Spam Canceller \ -i Subjec 1484
sed: -e expression #1, char 11: No previous regular expression
Hmmm... I didn't call sed at all here! Why's it complaining? Also, sometimes I get the
following:
Usage: formail [-vbczfrktqY] [-D nnn idcache] [-p prefix] [-l folder]
[-xXaAiIuU field] [-R ofield nfield]
Or: formail [+nnn] [-nnn] [-bczfrktedqBY] [-D nnn idcache] [-p prefix]
[-n [nnn]] [-m nnn] [-l folder] [-xXaAiIuU field] [-R ofield nfield]
-s [prg [arg ...]]
But that *is* how I am calling formail. Again, any ideas as to why this is happening?
I know that these are more procmail questions than Cygwin questions except this whole
setup was
transfered from my domain which was running FreeBSD and did not exhibit these problems.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Fwd: 1.3.10 gcc/g77 won't install, won't work
---BeginMessage--- Hi I had an awful week fighting with install. I kept getting the same error to do with being unable to find -user32. Folowing the isnstuctions about not sending messages to the list about old problems I persevered. The archive told me that this was to do with an incomplete download, so I tried and tried again from one of the Uk mirrors. (for five days) Eventually in desperation I tried a German mirror and reinstalled gcc. because the intelligent istall knows what files to install. The German mirror downloaded a half dozen files I didnt seem to have got from the Uk mirror. Boy was I glad when I finally got hello world to compile and run. I am a newby so I am by no means accusing any mirror of anything. I just found the simple download and isntall of all damn difficult. Regards Frank ---End Message--- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime
On Mon, Mar 25, 2002 at 04:48:49PM +0800, Wu Yongwei wrote: This is from the glibc documentation (is glibc meaningless to the Cygwin project?): Yes. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Fwd: 1.3.10 gcc/g77 won't install, won't work
At 11:41 AM 3/25/2002, you wrote: Return-path: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Full-name: Francis Domoney Message-ID: [EMAIL PROTECTED] Date: Mon, 25 Mar 2002 09:52:35 EST Subject: Re: 1.3.10 gcc/g77 won't install, won't work To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: AOL 7.0 for Windows UK sub 52 Hi I had an awful week fighting with install. I kept getting the same error to do with being unable to find -user32. Folowing the isnstuctions about not sending messages to the list about old problems I persevered. The archive told me that this was to do with an incomplete download, so I tried and tried again from one of the Uk mirrors. (for five days) Eventually in desperation I tried a German mirror and reinstalled gcc. because the intelligent istall knows what files to install. The German mirror downloaded a half dozen files I didnt seem to have got from the Uk mirror. Boy was I glad when I finally got hello world to compile and run. I am a newby so I am by no means accusing any mirror of anything. I just found the simple download and isntall of all damn difficult. Sorry for your problems. There is a bug in the current setup that causes it trouble when it installs packages in a form that it doesn't expect. This issue has been worked-around by repackaging the offending packages. You shouldn't see the -luser32 problem anymore but it may take some time to propagate to all the mirrors. Trying other mirrors if this problem occurs for you is a good strategy. The w32api package is the one at fault and is the only one you should need to redownload and reinstall if this problem occurs for you. There also may be an issue with the new setup's ability to correctly handle symbolic links. This has recently been reported as a possible cause of the problems people have been having getting g++ to properly install. The jury is still out on this one and the only work-around I can think of in the meantime if you're caught by this one is to install the gcc tar file manually (using tar, not WinZip!) Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Networking problem
On Mon, Mar 25, 2002 at 09:46:50AM -0500, Larry Hall (RFK Partners, Inc) wrote: At 01:02 AM 3/25/2002, Rajaraman B wrote: There is no support for IP_HDRINCL socket option. Many header files Check out Winsock capabilities in this area. Cygwin's socket support is dependent on Winsock functionality. Of course patches to augment Cygwin are always cheerfully accepted, too. If Winsock can do it, then Cygwin should be able to do it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New version of setup.exe broken when running with WINE
On Mon, Mar 25, 2002 at 03:07:55PM +0100, Sylvain Petreolle wrote: Seriously, Trying to run cygwin under WINE environment is a good testcase for both power companies (ie cygwin and wine :)). Sorry, but it is not. When an emulation environment does not properly emulate Windows and causes a problem with a program, then it is not the program's fault. I really don't understand this line of thinking. If you had a problem running Powerpoint under Wine would you report it to Microsoft? The goal of a bug entry created for wine is to run bash/sh in WINE environment. If someone is interested you can look at http://bugs.codeweavers.com/show_bug.cgi?id=443 Yeah, these are people reporting problems in *Wine*. Various cygwin programs function at this day (mount,ls, and several others). Thanks by advance, Sylvain. What are you thanking for? I'm pretty sure that no one who is working on cygwin or setup.exe is interested in expending effort to get things working on Wine. I'd certainly reject any patch that I saw whose sole purpose was to add Wine support to cygwin. To answer your question: Cygwin is the power company. Wine is the hair dryer. Fix the hair dryer. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Make 'include' directive with Cygnus bash - path problem
I have encountered a problem including makefiles. Here are two very simple example makefiles: *** First simple makefile: makefile TEMP=$(shell pwd) export # Including this works include c:/RIS/Software/3G_Platform_2_5_make/makefile.test # Including this fails #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test *** Second simple makefile (included by the first): makefile.test all: echo Hello World. echo $(TEMP) This is the good case: $ make all echo Hello World. Hello World. echo /cygdrive/c/RIS/Software/3G_Platform_2_5_make /cygdrive/c/RIS/Software/3G_Platform_2_5_make If I include the bash path /cygdrive/c/... etc I get the following error: $ make all makefile:4: /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test: No such file or directory c:\ris\bin\make.exe: *** No rule to make target `/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test'. Stop. Is this a bug in make? Or bash? Or am I missing something here. Please help. My set up: GNU make, Cygnus bash running on MS Windows 2000. !::='::\' !C:='C:\cygwin\bin' ALLUSERSPROFILE='C:\Documents and Settings\All Users' APPDATA='C:\Documents and Settings\ubirs\Application Data' BASH=/usr/bin/bash BASH_VERSINFO=([0]=2 [1]=05a [2]=0 [3]=3 [4]=release [5]=i686-pc-cygwin) BASH_VERSION='2.05a.0(3)-release' BIN_PATH='C:\RIS\bin' C6X_A_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6 000\rtdx\lib' C6X_C_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6 000\rtdx\lib' COLUMNS=80 COMMONPROGRAMFILES='C:\Program Files\Common Files' COMPUTERNAME=UBI-DEV1 COMSPEC='C:\WINNT\system32\cmd.exe' DIRSTACK=() EUID=500 GROUPS=() HISTFILE=/home/Administrator/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/Administrator HOMEDRIVE=C: HOMEPATH='\' HOSTNAME=UBI-DEV1 HOSTTYPE=i686 IFS=$' \t\n' LINES=25 LOGONSERVER='\\CAMATH01' MACHTYPE=i686-pc-cygwin MAILCHECK=60 MAKESHELL=/usr/bin/sh MAKE_MODE=unix NUMBER_OF_PROCESSORS=1 OLDPWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make/build OPTERR=1 OPTIND=1 OS=Windows_NT OS2LIBPATH='C:\WINNT\system32\os2\dll;' OSTYPE=cygwin PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin: /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem: /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk Shared/:/cygdrive/c/vslick/win' PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PIPESTATUS=([0]=2) PPID=1 PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER='x86 Family 15 Model 1 Stepping 2, GenuineIntel' PROCESSOR_LEVEL=15 PROCESSOR_REVISION=0102 PROGRAMFILES='C:\Program Files' PROMPT='$P$G' PS1=$'\\[\\033]0;\\w\\007\n\\033[32m\\]\\u@\\h \\[\\033[33m\\w\\033[0m\\]\n$ ' PS2=' ' PS4='+ ' PWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make ROOTDIR=c:/mks SHELL=/usr/bin/sh SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comme nts:emacs SHLVL=1 SYSTEMDRIVE=C: SYSTEMROOT='C:\WINNT' TEMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp TERM=cygwin TI_DIR='C:\ti' TMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp TMPDIR=/cygdrive/c/WINNT/TEMP UID=500 USER=Administrator USERDOMAIN=UK-MAIN USERNAME=UBIRS USERPROFILE='C:\Documents and Settings\ubirs' WINDIR='C:\WINNT' _=all i='/etc/profile.d/*.sh' GNU bash, version 2.05a.0(3)-release (i686-pc-cygwin) Copyright 2001 Free Software Foundation, Inc. GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for Windows32 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to [EMAIL PROTECTED]. FYI: I have sent the same email to GNU... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: procmail locking problem warning (was Re: procmail on cygwin)
Greg, On Sun, Mar 24, 2002 at 05:50:32AM +0800, Greg Matheson wrote: On Fri, 22 Mar 2002, Jason Tishler wrote: Occasionally, I would get errors such as the following in my procmail.log file: procmail: Error while writing to /var/spool/mail/jt procmail: Truncated file to former size Mmh. I see one such error in my procmail log. I guess that you are lucky then or your MUA only uses dotlocking (i.e., does not use fcntl). What MUA are you using? My MUA is mutt 1.3.24i and it uses both fcntl() and dotlocking. I have temporarily fixed the problem by commented out the #define NOfcntl_lock in autoconf.h while I wade through the obfuscated procmail coding style. An alternative would be not to look at your mail while downloading it. IMO, the above is unacceptable -- it defeats the whole purpose of running fetchmail as a daemon. Is there any reason for not crossposting your message to a procmail list, eg [EMAIL PROTECTED] or [EMAIL PROTECTED]? Just laziness. The number of people on both procmail and cygwin lists must be very small, but the procmail developers (ie Philip Guenther) should be made aware of the autoconf problem. Agreed, but I give no ETA. Although, note that this is important to me so it will probably happen sooner rather than later. Nevertheless, you are welcome to beat me to it. If so, then please CC me so I won't duplicate the effort. Thanks, Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.3.10 gcc/g77 won't install, won't work
Sorry for the font difficulty. I didn't test if binutils is working properly. But it shows its current version as 20011002-1 in cygwin's 'packages to install' list -- unlike the gcc package. And I didn't install g77 separately. I'm using g77 as the default subset of gcc package. And the problem is not limited to g77; gcc shows the same symptom. My trials do not include building g77 or gcc from source package. I only tried installing pre-compiled binaries. So I do not understand what you mean by 'spurious -lm in the default setup... does not extend to a separate version of gcc/g77 installed from source'. I know the version is NOT the problem; I said I saw the very version working on other machine. I mostly suspect the new setup.exe(v2.195.2.15). Can I get the old setup.exe(v2.125.2.10)? Tim Prince wrote: On Monday 25 March 2002 06:06, Ryu Myungsunn wrote: Recently I updated cygwin to 1.3.10 and got installation incomplete Check /setup.log.full message. but no /setup.log.full was found. Later I discovered that g77(v0.5.25) won't produce .exe files while producing .o files. This was the same with gcc(v2.95.3-5). The same versions of gcc and g77 work nicely on solaris7-sparc environment. Your font is quite difficult to read here. It's not your g77 version. You may have somehow introduced breakage (possibly in more than one place) in your g77 linkage setup. Since you give no particulars, anyone trying to help you would be guessing. You haven't even revealed whether you got binutils installed. One of the common problems with the cygwin setup is the introduction of a spurious -lm in the default g77 setup. Such breakage in the g77 version installed by cygwin does not necessarily extend to a separate version of gcc/g77 installed from source. -- Tim Prince -- ?? Ryu Myungsunn, Organic EL Group +82-2-526-4498 LG Elite ?? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make 'include' directive with Cygnus bash - path problem
On Mon, Mar 25, 2002 at 05:27:39PM -, Ronnie Shipman wrote: FYI: I have sent the same email to GNU... GNU doesn't support the version of make that comes from cygwin. If you want to see a problem fixed, you're going to have to debug make, fix it, and send a ChangeLog/patch here. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make 'include' directive with Cygnus bash - path problem
Send the following to the list: 1. Output of 'mount'. 2. Output of 'type make' 3. Output of 'cygcheck make' 4. Output of 'echo $MAKE_MODE' Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 12:27 PM 3/25/2002, Ronnie Shipman wrote: I have encountered a problem including makefiles. Here are two very simple example makefiles: *** First simple makefile: makefile TEMP=$(shell pwd) export # Including this works include c:/RIS/Software/3G_Platform_2_5_make/makefile.test # Including this fails #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test *** Second simple makefile (included by the first): makefile.test all: echo Hello World. echo $(TEMP) This is the good case: $ make all echo Hello World. Hello World. echo /cygdrive/c/RIS/Software/3G_Platform_2_5_make /cygdrive/c/RIS/Software/3G_Platform_2_5_make If I include the bash path /cygdrive/c/... etc I get the following error: $ make all makefile:4: /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test: No such file or directory c:\ris\bin\make.exe: *** No rule to make target `/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test'. Stop. Is this a bug in make? Or bash? Or am I missing something here. Please help. My set up: GNU make, Cygnus bash running on MS Windows 2000. !::='::\' !C:='C:\cygwin\bin' ALLUSERSPROFILE='C:\Documents and Settings\All Users' APPDATA='C:\Documents and Settings\ubirs\Application Data' BASH=/usr/bin/bash BASH_VERSINFO=([0]=2 [1]=05a [2]=0 [3]=3 [4]=release [5]=i686-pc-cygwin) BASH_VERSION='2.05a.0(3)-release' BIN_PATH='C:\RIS\bin' C6X_A_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6 000\rtdx\lib' C6X_C_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\lib;.;C:\ti\c 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\include;C:\ti\c6 000\rtdx\lib' COLUMNS=80 COMMONPROGRAMFILES='C:\Program Files\Common Files' COMPUTERNAME=UBI-DEV1 COMSPEC='C:\WINNT\system32\cmd.exe' DIRSTACK=() EUID=500 GROUPS=() HISTFILE=/home/Administrator/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/Administrator HOMEDRIVE=C: HOMEPATH='\' HOSTNAME=UBI-DEV1 HOSTTYPE=i686 IFS=$' \t\n' LINES=25 LOGONSERVER='\\CAMATH01' MACHTYPE=i686-pc-cygwin MAILCHECK=60 MAKESHELL=/usr/bin/sh MAKE_MODE=unix NUMBER_OF_PROCESSORS=1 OLDPWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make/build OPTERR=1 OPTIND=1 OS=Windows_NT OS2LIBPATH='C:\WINNT\system32\os2\dll;' OSTYPE=cygwin PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin: /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem: /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk Shared/:/cygdrive/c/vslick/win' PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PIPESTATUS=([0]=2) PPID=1 PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER='x86 Family 15 Model 1 Stepping 2, GenuineIntel' PROCESSOR_LEVEL=15 PROCESSOR_REVISION=0102 PROGRAMFILES='C:\Program Files' PROMPT='$P$G' PS1=$'\\[\\033]0;\\w\\007\n\\033[32m\\]\\u@\\h \\[\\033[33m\\w\\033[0m\\]\n$ ' PS2=' ' PS4='+ ' PWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make ROOTDIR=c:/mks SHELL=/usr/bin/sh SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comme nts:emacs SHLVL=1 SYSTEMDRIVE=C: SYSTEMROOT='C:\WINNT' TEMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp TERM=cygwin TI_DIR='C:\ti' TMP=/cygdrive/c/DOCUME~1/ubirs/LOCALS~1/Temp TMPDIR=/cygdrive/c/WINNT/TEMP UID=500 USER=Administrator USERDOMAIN=UK-MAIN USERNAME=UBIRS USERPROFILE='C:\Documents and Settings\ubirs' WINDIR='C:\WINNT' _=all i='/etc/profile.d/*.sh' GNU bash, version 2.05a.0(3)-release (i686-pc-cygwin) Copyright 2001 Free Software Foundation, Inc. GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for Windows32 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to [EMAIL PROTECTED]. FYI: I have sent the same email to GNU... -- Unsubscribe info:
Re: 1.3.10 gcc/g77 won't install, won't work
Thanks Larry as the instgructions about the mailing list says you don't half feel virtuous when it goes in the end without having to ask for help per ardua ad astra as they say. Regards Frank -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New version of setup.exe broken when running with WINE
Sorry, but it is not. When an emulation environment does not properly emulate Windows and causes a problem with a program, then it is not the program's fault. I agree with you, but in that case, setup.exe wouldn't have function by the past ... I really don't understand this line of thinking. If you had a problem running Powerpoint under Wine would you report it to Microsoft? Has been made many times by us... and then more web sites are talking about compatibility of their programs with Wine. Let's take HeadLight Software example. After a few bug reports, they put a page about Wine and GetRight ... it's running properly under Wine today. Yeah, these are people reporting problems in *Wine*. Not only. Cygwin Bash is doing (maybe ?) unwanted access to COM1 port when run under Wine for example I'd certainly reject any patch that I saw whose sole purpose was to add Wine support to cygwin. To answer your question: Cygwin is the power company. Wine is the hair dryer. Fix the hair dryer. Please give me a try : Cygwin Wine are 2 power companies... It would be great to make a dialog to fix problems of the BOTH parts, not only one... You 'll only have benefit Note that I use both Wine and cygwin today... ___ Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make 'include' directive with Cygnus bash - path problem
Hi Ronnie, Ronnie Shipman wrote: I have encountered a problem including makefiles. SNIP # Including this works include c:/RIS/Software/3G_Platform_2_5_make/makefile.test # Including this fails #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test SNIP PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygdrive/c/ti/bi n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x86-win32/bin: /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/mks/mksnt:/cy gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem: /cygdrive/c/oracle/ora81/bin:/cygdrive/c/Program Files/Oracle/jre/1.1.7/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/c ygdrive/c/WINNT/System32/Wbem:/cygdrive/c/PROGRA~1/COMMON~1/Autodesk Shared/:/cygdrive/c/vslick/win' SNIP ROOTDIR=c:/mks SNIP GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for Windows32 SNIP You seem to be running a non-cygwin version of GNU make 3.79.1. The CygWin version says: GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-cygwin --^^ That version will not know about /cygdrive/... Try the cygwin version. Regards, Johan Bezem CSK Software AG -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Make 'include' directive with Cygnus bash - path problem
More info: $ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) b: on /cygdrive/b type user (binmode,noumount) c: on /cygdrive/c type user (binmode,noumount) l: on /cygdrive/l type user (binmode,noumount) r: on /cygdrive/r type user (binmode,noumount) s: on /cygdrive/s type user (binmode,noumount) t: on /cygdrive/t type user (binmode,noumount) u: on /cygdrive/u type user (binmode,noumount) v: on /cygdrive/v type user (binmode,noumount) $ type make make is hashed (/cygdrive/c/ris/bin/make) $ cygcheck make Found: c:\ris\bin\make.exe Found: c:\Tornado\host\x86-win32\bin\make.exe Found: c:\gcc-2.95.2\bin\make.exe Found: c:\mks\mksnt\make.exe c:\ris\bin\make.exe C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.DLL Use -h to see help about each section $ echo $MAKE_MODE unix And to answer to obvious question: $ ls -la /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test -rw-r--r--1 Administ None 39 Mar 25 14:40 /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test $ ls -la c:/RIS/Software/3G_Platform_2_5_make/makefile.test -rw-r--r--1 Administ None 39 Mar 25 14:40 c:/RIS/Software/3G_Platform_2_5_make/makefile.test -Original Message- From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]] Sent: 25 March 2002 17:44 To: Ronnie Shipman; '[EMAIL PROTECTED]' Subject: Re: Make 'include' directive with Cygnus bash - path problem Send the following to the list: 1. Output of 'mount'. 2. Output of 'type make' 3. Output of 'cygcheck make' 4. Output of 'echo $MAKE_MODE' Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 12:27 PM 3/25/2002, Ronnie Shipman wrote: I have encountered a problem including makefiles. Here are two very simple example makefiles: *** First simple makefile: makefile TEMP=$(shell pwd) export # Including this works include c:/RIS/Software/3G_Platform_2_5_make/makefile.test # Including this fails #include /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test *** Second simple makefile (included by the first): makefile.test all: echo Hello World. echo $(TEMP) This is the good case: $ make all echo Hello World. Hello World. echo /cygdrive/c/RIS/Software/3G_Platform_2_5_make /cygdrive/c/RIS/Software/3G_Platform_2_5_make If I include the bash path /cygdrive/c/... etc I get the following error: $ make all makefile:4: /cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test: No such file or directory c:\ris\bin\make.exe: *** No rule to make target `/cygdrive/c/RIS/Software/3G_Platform_2_5_make/makefile.test'. Stop. Is this a bug in make? Or bash? Or am I missing something here. Please help. My set up: GNU make, Cygnus bash running on MS Windows 2000. !::='::\' !C:='C:\cygwin\bin' ALLUSERSPROFILE='C:\Documents and Settings\All Users' APPDATA='C:\Documents and Settings\ubirs\Application Data' BASH=/usr/bin/bash BASH_VERSINFO=([0]=2 [1]=05a [2]=0 [3]=3 [4]=release [5]=i686-pc-cygwin) BASH_VERSION='2.05a.0(3)-release' BIN_PATH='C:\RIS\bin' C6X_A_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\l ib;.;C:\ti\c 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\incl ude;C:\ti\c6 000\rtdx\lib' C6X_C_DIR='.;C:\ti\c6000\cgtools\include;C:\ti\c6000\cgtools\l ib;.;C:\ti\c 6000\bios\include;C:\ti\c6000\bios\lib;.;C:\ti\c6000\rtdx\incl ude;C:\ti\c6 000\rtdx\lib' COLUMNS=80 COMMONPROGRAMFILES='C:\Program Files\Common Files' COMPUTERNAME=UBI-DEV1 COMSPEC='C:\WINNT\system32\cmd.exe' DIRSTACK=() EUID=500 GROUPS=() HISTFILE=/home/Administrator/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/Administrator HOMEDRIVE=C: HOMEPATH='\' HOSTNAME=UBI-DEV1 HOSTTYPE=i686 IFS=$' \t\n' LINES=25 LOGONSERVER='\\CAMATH01' MACHTYPE=i686-pc-cygwin MAILCHECK=60 MAKESHELL=/usr/bin/sh MAKE_MODE=unix NUMBER_OF_PROCESSORS=1 OLDPWD=/cygdrive/c/RIS/Software/3G_Platform_2_5_make/build OPTERR=1 OPTIND=1 OS=Windows_NT OS2LIBPATH='C:\WINNT\system32\os2\dll;' OSTYPE=cygwin PATH='/usr/local/bin:/usr/bin:/bin:.:/cygdrive/c/ris/bin:/cygd rive/c/ti/bi n:/cygdrive/c/ti/c6000/cgtools/bin:/cygdrive/c/Tornado/host/x8 6-win32/bin: /cygdrive/c/gcc-2.95.2/bin:/cygdrive/c/mks/mkssi:/cygdrive/c/m ks/mksnt:/cy gdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/Sy stem32/Wbem:
RE: Make 'include' directive with Cygnus bash - path problem
At 12:52 PM 3/25/2002, Ronnie Shipman wrote: More info: $ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) b: on /cygdrive/b type user (binmode,noumount) c: on /cygdrive/c type user (binmode,noumount) l: on /cygdrive/l type user (binmode,noumount) r: on /cygdrive/r type user (binmode,noumount) s: on /cygdrive/s type user (binmode,noumount) t: on /cygdrive/t type user (binmode,noumount) u: on /cygdrive/u type user (binmode,noumount) v: on /cygdrive/v type user (binmode,noumount) $ type make make is hashed (/cygdrive/c/ris/bin/make) $ cygcheck make Found: c:\ris\bin\make.exe Found: c:\Tornado\host\x86-win32\bin\make.exe Found: c:\gcc-2.95.2\bin\make.exe Found: c:\mks\mksnt\make.exe c:\ris\bin\make.exe C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\NTDLL.DLL C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.DLL OK. Just as I thought and as Johan Bezem picked up on with the previous information you sent. Your problem is as he states. Use the Cygwin version of make and you won't have the problem you're reporting. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Make 'include' directive with Cygnus bash - path problem
On Mon, Mar 25, 2002 at 05:52:48PM -, Ronnie Shipman wrote: More info: We don't need more info: http://sources.redhat.com/ml/cygwin/2002-03/msg01428.html http://sources.redhat.com/ml/cygwin/2002-03/msg01432.html The first reference tells you what you need to do if this was a cygwin problem. The second reference points out that you are not running a cygwin version of make. Don't expect a non-cygwin version of make to understand /cygdrive constructions. Let's end this thread now. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New version of setup.exe broken when running with WINE
On Mon, Mar 25, 2002 at 06:50:35PM +0100, Sylvain Petreolle wrote: Sorry, but it is not. When an emulation environment does not properly emulate Windows and causes a problem with a program, then it is not the program's fault. I agree with you, but in that case, setup.exe wouldn't have function by the past ... Sorry, but I can't parse this sentence. If you are saying that a previous version setup used to work in Wine, then the answer to that is So? We're not going to confine ourselves to only using things which work on Wine. I really don't understand this line of thinking. If you had a problem running Powerpoint under Wine would you report it to Microsoft? Has been made many times by us... and then more web sites are talking about compatibility of their programs with Wine. Let's take HeadLight Software example. After a few bug reports, they put a page about Wine and GetRight ... it's running properly under Wine today. That's just great for them. As I said, this isn't a goal for cygwin. Or, rather, if there are ways to configure wine such that it works better with cygwin, then, sure, we can make that information available. We're not going to modify cygwin to accomodate Wine. Yeah, these are people reporting problems in *Wine*. Not only. Cygwin Bash is doing (maybe ?) unwanted access to COM1 port when run under Wine for example Again, the answer is So? If bash is working correctly in its native environment (Windows 9x/Me/NT/2000/XP), then it is working as designed. If it is not working well on Wine, then it is very likely to be A WINE PROBLEM. If there is a real problem lurking somewhere that only manifests on Wine for some reason, then you're welcome to debug it and submit a patch. Since it doesn't seem to be affecting any of the audience for which Cygwin was targetted, it is a non-issue for me, right now. This is partially a practical matter. Debugging a system like Wine complicates things enormously. Even if cygwin was doing something strange with com ports, it could potentially take a lot of time convincing oneself that this wasn't actually a Wine problem. That would mean debugging Wine to see what was going on. Personally, I have no interest and no time for such an undertaking. I'd certainly reject any patch that I saw whose sole purpose was to add Wine support to cygwin. To answer your question: Cygwin is the power company. Wine is the hair dryer. Fix the hair dryer. Please give me a try : Cygwin Wine are 2 power companies... It would be great to make a dialog to fix problems of the BOTH parts, not only one... You 'll only have benefit As far as analogies go, the concept of two power companies doesn't work anyway. Anyway, to reiterate for the final time, if you want problems fixed that manifest in Wine, you're probably on your own. That's not a big deal however. The source code is available. If you find an actual bug there is no reason why you can't fix it. By and large, this is how free software development works. If you see a need, it is much much more likely to get filled if you volunteer the time to do it yourself. That is what the miniscule number of people working on this project are doing. And, please don't come back with the Not a programmer, don't have time, it's to your benefit argument. None of those are relevant. If you are unable to do the work yourself then continuing to assert that it is of some nebulous benefit to cygwin is fruitless. Your best (and sometimes only) leverage in a free software project is your own contribution. Contributing arguments is often just a polarizing activity. It doesn't get any work done and just ends up pulling people away from things that they could be doing. It's possible that Wine *is* of some importance to someone who is working on setup.exe or cygwin. If it is, more power to them. If this mythical person starts submitting patches, however, I'm certainly going to be inspecting them closely to make sure that we aren't adding workarounds just for Wine. If the patch entailed a way of doing things that worked around a problem in Wine without impacting the code in any way either performance-wise or clarity-wise, I'd probably accept it. That's it. I think I've made myself very clear on this issue. I won't be responding further. cgf -- Please do not send me personal email with cygwin questions. Use the resources at http://cygwin.com/ . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
link error - missing user32?
I just installed cygwin for the first time and I am having trouble linking hello.c on Win2k. I read the FAQ and did a search in the archives for similar errors. Although I found references to the same problem, I was not able to resolve it by follow the same course of action as the other users. So far I have: -reinstalled everything -reinstalled the w32 libs Error is below: $ gcc hello.c /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann ot find -luser32 collect2: ld returned 1 exit status Any other suggestions? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: HELP: rxvt configuration
Thanks for your reply :) I think that I understood my error concerning the menus in RXVT: In my .Xdefaults file, I set the '.path' resource to '$HOME'...when, rxvt read this file, the HOME and the USER variables don't seem to be still defined... so, rxvt cannot open my menu :( This explains also why, when I open rxvt from rxvt terminal, the menu is properly displayed: in this case, rxvt can use the current values of theses variables... Now, I set the '.path' resource to '/home/Philippe' and all seems ok... but, I think that it is not the best solution... How you resolved this problem ? a+ Philippe -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: link error - missing user32?
At 02:28 PM 3/25/2002, Mark Rubin wrote: I just installed cygwin for the first time and I am having trouble linking hello.c on Win2k. I read the FAQ and did a search in the archives for similar errors. Although I found references to the same problem, I was not able to resolve it by follow the same course of action as the other users. So far I have: -reinstalled everything -reinstalled the w32 libs Error is below: $ gcc hello.c /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann ot find -luser32 collect2: ld returned 1 exit status Any other suggestions? You'll need to be more specific about what you did and saw if you want reasonable suggestions. There's only two things I can suggest you try at this point: 1. Use the setup from www.cygwin.com if you did not. 2. Debug the problem. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: link error - missing user32?
I resolved the issue by following the course of action listed in: http://www.cygwin.com/ml/cygwin/2002-03/msg01262.html I am not sure if this the best approach, but it worked. -Original Message- From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]] Sent: Monday, March 25, 2002 11:43 AM To: Mark Rubin; [EMAIL PROTECTED] Subject: Re: link error - missing user32? At 02:28 PM 3/25/2002, Mark Rubin wrote: I just installed cygwin for the first time and I am having trouble linking hello.c on Win2k. I read the FAQ and did a search in the archives for similar errors. Although I found references to the same problem, I was not able to resolve it by follow the same course of action as the other users. So far I have: -reinstalled everything -reinstalled the w32 libs Error is below: $ gcc hello.c /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann ot find -luser32 collect2: ld returned 1 exit status Any other suggestions? You'll need to be more specific about what you did and saw if you want reasonable suggestions. There's only two things I can suggest you try at this point: 1. Use the setup from www.cygwin.com if you did not. 2. Debug the problem. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: link error - missing user32?
Good. But you shouldn't need to do this unless the w32api package you downloaded is not current. If it contains './' at the start of the paths in the tar file, then it's not current. You would need to either do what you did or delete and redownload a new w32api package, perhaps from a different mirror. However, the current problem with setup that caused this issue has been worked-around by repackaging w32api with the './' parts removed so you shouldn't see this problem with any current download of w32api. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 02:56 PM 3/25/2002, Mark Rubin wrote: I resolved the issue by following the course of action listed in: http://www.cygwin.com/ml/cygwin/2002-03/msg01262.html I am not sure if this the best approach, but it worked. -Original Message- From: Larry Hall (RFK Partners, Inc) [mailto:[EMAIL PROTECTED]] Sent: Monday, March 25, 2002 11:43 AM To: Mark Rubin; [EMAIL PROTECTED] Subject: Re: link error - missing user32? At 02:28 PM 3/25/2002, Mark Rubin wrote: I just installed cygwin for the first time and I am having trouble linking hello.c on Win2k. I read the FAQ and did a search in the archives for similar errors. Although I found references to the same problem, I was not able to resolve it by follow the same course of action as the other users. So far I have: -reinstalled everything -reinstalled the w32 libs Error is below: $ gcc hello.c /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld: cann ot find -luser32 collect2: ld returned 1 exit status Any other suggestions? You'll need to be more specific about what you did and saw if you want reasonable suggestions. There's only two things I can suggest you try at this point: 1. Use the setup from www.cygwin.com if you did not. 2. Debug the problem. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Programs fail to recognize paths.
/ Michael Labhard [EMAIL PROTECTED] wrote: | While trying to use cvs on cygwin (Windows XP) the command cvs -d | /usr/local/cvs-repository update returns the error directory | /usr/local/cvs-repostory does not exist. ls has no problem finding the Well the cvs you use has to be compiled with cygwin, sounds like it is not, try to ask it to look in c:/cygwin/usr/local/cvs-repository or with dos-ish backslashes.. /Andy -- The eye of the beholder rests on the beauty! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Visual debugging tools for Cygwin.
Are there any semi-visual front ends for GDB, like RHIDE, for Cygwin? I seem to remember Cygnus/RedHat used to sell one, is it still for sale, or now available elsewhere? Warren -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Visual debugging tools for Cygwin.
At 04:03 PM 3/25/2002, Warren Postma wrote: Are there any semi-visual front ends for GDB, like RHIDE, for Cygwin? I seem to remember Cygnus/RedHat used to sell one, is it still for sale, or now available elsewhere? Can you be more specific? What constitutes a semi-visual front end for gdb? Should we assume that Insight isn't what you're looking for? Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Strange behavior of MSVC's printf under cygwin shell?
Hi,
Why does the screen output displayed using MSVC's printf subroutine not get
shown immediately under Cygwin shell (bash, specifically)? Rather, it would
wait for a long time before showing the text lines (many lines at once). How
to change this behavior?
I used the following (simple) code as an example:
#includestdio.h
int main() {
for (int i=0; i 50; ++i) {
printf(%d %d\n, i, i*i);
for (int j=0; j 1000; ++j); /* just for delay */
}
return 0;
}
Try to compile it using: gcc -mno-cygwin sample.c , then run it: ./a.exe. If
you remove -mno-cygwin, this strange behavior disappears. Under MS-DOS
shell, this behavior does not exist.
Thanks,
Wirawan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Strange behavior of MSVC's printf under cygwin shell?
At 04:38 PM 3/25/2002, Wirawan Purwanto wrote:
Hi,
Why does the screen output displayed using MSVC's printf subroutine not get
shown immediately under Cygwin shell (bash, specifically)? Rather, it would
wait for a long time before showing the text lines (many lines at once). How
to change this behavior?
I used the following (simple) code as an example:
#includestdio.h
int main() {
for (int i=0; i 50; ++i) {
printf(%d %d\n, i, i*i);
for (int j=0; j 1000; ++j); /* just for delay */
}
return 0;
}
Try to compile it using: gcc -mno-cygwin sample.c , then run it: ./a.exe. If
you remove -mno-cygwin, this strange behavior disappears. Under MS-DOS
shell, this behavior does not exist.
The problem must be at your end. I don't see it here. Looks like you'll
need to debug it more.
Larry Hall [EMAIL PROTECTED]
RFK Partners, Inc. http://www.rfk.com
838 Washington Street (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
setup.exe crash
Hi I have setup.exe point to a local network mapping for its local Package directory. I noticed when I rebooted, not having the mapping set up to reconnect, that setup.exe crashed when it tried to move on from that screen with the following error; The exception unknown software exception (0xc0fd) occurred in the application at location 0x77f7f12a. That was the only trouble its given me. setup.exe version 2.194.2.15 Wint4 sp6a -Coley. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ocdemon gdbinit mpc860T upm init
Hello - I am trying to work with cygwin ocdemon a custom MPC860T board with SDRAM. I need to create a command file to initialize the 860T UPM so that I can download code into RAM. Are there any examples available? The gdbinit_823FADS example is not enough! Thanks, Jon Miller 805-564-3119 (My goal is setup free tools to burn PPCBOOT into custom MPC8xx boards.) $powerpc-elf-gdb -- command=gdbinit_860Tregs_upm -- gdb startup? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gdb and win32
I am using a virtual serial port driver (from ddiusa.com) to connect gdb to a target simulation through the virtual serial ports. gdb hangs whenever I attempt to connect. It works fine when using the *real* serial ports, but hangs whenever I attempt to use the virtual ports. The virtual port software works with other win32 applications, and the docs say they drivers do not support DOS apps. Is gdb considered a DOS app? Does it use the win32 API to talk to the serial ports? All I can find in the code is calls to open, read and write, not OpenFile, ReadFile or WriteFile as I would expect for a win32 application. Bill -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behavior of MSVC's printf under cygwin shell?
I have frequently seen unpredictable behavior of C prints in terms of their timing. (I'm an old guy and I still debug with prints from time to time). The only way I got predictable results was to do a buffer flush immediately after the print. In my case, if I didn't do that, and the program crashed, sometimes I would never see my diagnostic prints. I have seen this on the SGI and the PC, but I can't swear that the PC was using VC++, it may have been Borland, or Cygwin or... Wayne Keen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin1.dll bug in ftime
Thank you for your suggestions. The points are: 1) Cygwin did very well, but not now; That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS. 2) I was not using ftime to get time, but to get timezone information. OK, another quote from the SUSv3 docs http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html: --- FUTURE DIRECTIONS This function may be withdrawn in a future version. --- [This wasn't in the SUSv2 docs, though.] So, _do not_ use this function to get time or timezone information. 3) timezone variable is not usable in Cygwin. Why not? In my installation 1.3.10 installation I see this in the time.h header file: --- #ifndef timezone #define timezone ((long int) _timezone) #endif --- And _timezone is declared some lines above: --- extern __IMPORT time_t _timezone; --- This is not strictly following the SUSv2 or SUSv3 standards, but it should work. SUSv2 says: --- The following are declared as variables: extern int daylight; extern long int timezone; extern char *tzname[]; --- SUSv3 says: --- The following shall be declared as variables: extern intdaylight; extern long timezone; extern char *tzname[]; --- timezone is a macro on Cygwin, but the typecast is OK. You can dig through the Cygwin sources and send in a patch to make Cygwin fully SUS compliant. So timezone is now not portable. Cygwin broke some unportable code. It didn't talk about unportable code. What I was trying to say is, that you wrote code that doesn't follow the standards and that is likely to break on any other platform. Read the SUSv2 at the link that Christopher Faylor gave you already. SUSv3 is quite new, so it's likely that other platforms are not really compliant to this new standard, yet. Karsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gdb and win32
At 05:55 PM 3/25/2002, William Hubbard wrote: I am using a virtual serial port driver (from ddiusa.com) to connect gdb to a target simulation through the virtual serial ports. gdb hangs whenever I attempt to connect. It works fine when using the *real* serial ports, but hangs whenever I attempt to use the virtual ports. The virtual port software works with other win32 applications, and the docs say they drivers do not support DOS apps. Is gdb considered a DOS app? Does it use the win32 API to talk to the serial ports? All I can find in the code is calls to open, read and write, not OpenFile, ReadFile or WriteFile as I would expect for a win32 application. gdb that comes with Cygwin is not considered a DOS app. It is a Win32 app. The gdb code itself is ported to Win32 using the Cygwin DLL so you won't find Win32 calls made in the gdb source. You'll need to look at the Cygwin DLL source to find those calls. I haven't the foggiest idea what the problem is when using your virtual serial port driver. You may need to debug gdb to find the problem. Or talk to the vendor and get some details about how it works and what it expects. That might help lead you in the right direction. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Shared libraries.
Hallo Wiebe,
Am 2002-03-25 um 16:12 schriebst du:
I'm trying to build and use shared libraries with Cygwin under Windows 2000.
The first step, i.e. building the library, succeeds. I get a libmylib.so
(together with libmylib.so.1 and limmylib.so.1.0.0). However, linking is a
problem. I've written a small program which uses libmylib.so and try to link
it as follows:
g++ -o testprogram.exe testprogram.o -L/usr/src/DynLib -lmylib
This results in the error:
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cannot find -lmylib
For information the entire output when executing make clean:
rm -f PrintTest.o PrintTest.exe.exe PrintTest.d *~
make
make[1]: Entering directory `/usr/src/dynlibtest'
g++ -M -Wall PrintTest.cpp PrintTest.d
g++ -M -Wall PrintTest.cpp | sed s/\\.o/.d/ PrintTest.d
make[1]: Leaving directory `/usr/src/dynlibtest'
make[1]: Entering directory `/usr/src/dynlibtest'
g++ -Wall-c -o PrintTest.o PrintTest.cpp
g++ -o PrintTest.exe PrintTest.o -L/usr/src/DynLib -lmylib
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/bin/ld:
cannot find -lmylib
collect2: ld returned 1 exit status
make[1]: *** [PrintTest.exe] Error 1
make[1]: Leaving directory `/usr/src/dynlibtest'
make: *** [clean] Error 2
When using:
g++ -o PrintTest.exe PrintTest.o libmylib.so
I get the error:
collect2: ld terminated with signal 11 [Segmentation fault]
Can someone tell me what I'm doing wrong?
You cannot act with windows like with linux. On windows shared libs
are dynamic link libraries (mylib.dll), and you cannot use symlinks to
point to a dll. Say mylib-0.1.dll is you lib and mylib.dll is the
symlink then it is not possible to link against the symlink, windows
doesn't accept this as a library. Anyway, we don't use the .dll's to
link against, but a special library called import library.
Looks like this (Cygwin default name) libmylib.dll.a, so we can have
also libmylib.a as the static lib.
Now if you link against this lib you write: gcc -o prog -I/lib -lmylib
The linker looks at first for libmylib.dll.a, then if there is no
importlib it looks for a static lib.
I always try to build a static lib at first.
If it succeeds it is just one step to get a dynamic link library from
these objects:
gcc -shared -o cyg${module}.dll -Wl,--out-implib=lib${module}.dll.a \
-Wl,--export-all-symbols \
-Wl,--enable-auto-import \
-Wl,--whole-archive $old_lib \
-Wl,--no-whole-archive ${dependency_libs}
The last (-Wl,--no-whole-archive) is important, even if you have no
dependency_libs. Don't miss it!
${module} is 'mylib' to stay with your example and $old_lib is libmylib.a,
the static lib. As an alternativ you can list all the objects here instead
of a static lib which is in fact just a bundle of object files.
HTH,
Gerrit
--
=^..^=
Maybe Charles will find some time to finish his docu about creating dll's;)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Perl module DBD::ODBC 0.39 wont compile on CYGWIN
Hallo Paul, Am 2002-03-25 um 23:33 schriebst du: DBD::ODBC Version 0.38 builds and passes the tests, but 0.39 wont even compile. Here are the error messages: $ make cp ODBC.pm blib/lib/DBD/ODBC.pm /usr/bin/perl -p -e s/~DRIVER~/ODBC/g /usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI/Driver.xst ODBC.xsi /usr/bin/perl -I/usr/lib/perl5/5.6.1/cygwin-multi -I/usr/lib/perl5/5.6.1 /usr/lib/perl5/5.6.1/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.6.1/ExtUtils/typemap ODBC.xs ODBC.xsc mv ODBC.xsc ODBC.c gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include -DUSEIMPORTLIB -O2 -DVERSION=\0.39\ -DXS_VERSION=\0.39\ -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE ODBC.c gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include -DUSEIMPORTLIB -O2 -DVERSION=\0.39\ -DXS_VERSION=\0.39\ -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE dbdimp.c dbdimp.c: In function `odbc_db_login6': dbdimp.c:211: `SQL_ATTR_ODBC_VERSION' undeclared (first use in this function) dbdimp.c:211: (Each undeclared identifier is reported only once dbdimp.c:211: for each function it appears in.) dbdimp.c:211: `SQL_IS_INTEGER' undeclared (first use in this function) dbdimp.c: At top level: dbdimp.c:1644: warning: `_dbd_rebind_ph' was declared implicitly `extern' and later `static' dbdimp.c:1190: warning: previous declaration of `_dbd_rebind_ph' make: *** [dbdimp.o] Error 1 When I look, the undeclared symbols are really, truly undefined. SQL_ATTR_ODBC_VERSION does not even appear to exist in version 0.38. Siebenschlaefer@LORELEY /usr/include $ grep -r SQL_IS_INTEGER * w32api/sqlext.h:#define SQL_IS_INTEGER (-6) Siebenschlaefer@LORELEY /usr/include $ grep -r SQL_ATTR_ODBC_VERSION * w32api/sqlext.h:#define SQL_ATTR_ODBC_VERSION 200 (BTW, as far as I can tell, the patch file used some time ago by CYGWIN users to fix the Makefile.pl has been fully incorporated into more recent builds, so I know that is not the problem.) It seems that there was no Cygwin user working on this module;) Try to include sqlext.h, ah at first take a look at this old patch, look how Eric Fifer solved the issue (windows.h needs to be included but immediatly after that WIN32 is undefined): http://testers.cpan.org/search?request=distdist=DBD-ODBCmacid=130 Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Strange behavior of MSVC's printf under cygwin shell?
Wirawan Purwanto wrote: Why does the screen output displayed using MSVC's printf subroutine not get shown immediately under Cygwin shell (bash, specifically)? Rather, it would wait for a long time before showing the text lines (many lines at once). How to change this behavior? With -mno-cygwin, stdout is buffered. You can realize it if you put a fflush(stdout) after the printf: the behavior is what you expect. But, why this difference? I don't know. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Setup.exe: bugfix
I've uploaded a new setup.exe that fixes the crashing problem experienced by some folk. Many thanks to Pavel Tsekov for solving this. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Perl module DBD::ODBC 0.39 wont compile on CYGWIN
DBD::ODBC Version 0.38 builds and passes the tests, but 0.39 wont even compile. Here are the error messages: $ make cp ODBC.pm blib/lib/DBD/ODBC.pm /usr/bin/perl -p -e s/~DRIVER~/ODBC/g /usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI/Driver.xst ODBC.xsi /usr/bin/perl -I/usr/lib/perl5/5.6.1/cygwin-multi -I/usr/lib/perl5/5.6.1 /usr/lib/perl5/5.6.1/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.6.1/ExtUtils/typemap ODBC.xs ODBC.xsc mv ODBC.xsc ODBC.c gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include -DUSEIMPORTLIB -O2 -DVERSION=\0.39\ -DXS_VERSION=\0.39\ -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE ODBC.c gcc -c -I. -I/usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/DBI -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/local/include -DUSEIMPORTLIB -O2 -DVERSION=\0.39\ -DXS_VERSION=\0.39\ -I/usr/lib/perl5/5.6.1/cygwin-multi/CORE dbdimp.c dbdimp.c: In function `odbc_db_login6': dbdimp.c:211: `SQL_ATTR_ODBC_VERSION' undeclared (first use in this function) dbdimp.c:211: (Each undeclared identifier is reported only once dbdimp.c:211: for each function it appears in.) dbdimp.c:211: `SQL_IS_INTEGER' undeclared (first use in this function) dbdimp.c: At top level: dbdimp.c:1644: warning: `_dbd_rebind_ph' was declared implicitly `extern' and later `static' dbdimp.c:1190: warning: previous declaration of `_dbd_rebind_ph' make: *** [dbdimp.o] Error 1 When I look, the undeclared symbols are really, truly undefined. SQL_ATTR_ODBC_VERSION does not even appear to exist in version 0.38. (BTW, as far as I can tell, the patch file used some time ago by CYGWIN users to fix the Makefile.pl has been fully incorporated into more recent builds, so I know that is not the problem.) I just upgraded today to the latest version of CYGWIN, and with it comes perl v5.6.1. - Paul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paul Anton Chernoch Zeborg, Inc. 500 West Cummings Park Woburn, MA 01801 t: 781.759.0105 f: 781.935.5090 c: 781.606.7382 http://www.zeborg.com This message is a personal and confidential communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: missing telnet, solution
This whole thread got me thinking about possible ways to avoid this xxx is missing problem... I thought that I'd throw an idea out for discussion... Would it make sense to have setup install a dummy script for some of the common utilities and then overwrite that script with the actual utility if it is selected from the gui as it should be? Assume that the missing utility is called ttt.exe Have setup create /bin/missing and link ttt.exe to missing ln -s /bin/missing /bin/telnet.exe stuckymb [547] ls -l missing ttt.exe -rwxr-xr-x1 stuckymb mygroup 214 Mar 25 18:00 missing lrwxrwxrwx1 stuckymb mygroup94 Mar 25 17:58 ttt.exe - missing stuckymb [548] stuckymb [548] stuckymb [548] stuckymb [548] cat missing #!/bin/sh echo If you are seeing this message, it means that the echo echo$0 echo echo 'still needs to be selected from within setup' echo echo 'Please re-run setup' echo stuckymb [549] stuckymb [549] stuckymb [549] stuckymb [549] ttt.exe If you are seeing this message, it means that the ./ttt.exe still needs to be selected from within setup Please re-run setup When setup is re-run to download the actual ttt.exe the dummy ttt.exe could be deleted and then replaced with the correct executable. Just my 0.02 cents worth... --Mark - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 23, 2002 9:46 PM Subject: Re: missing telnet, solution On Sat, Mar 23, 2002 at 06:18:05PM +0100, Palic, Darko wrote: Hello Christopher, okay it is nice to follow the request of the users, but why isn't a selectbox available, there something like basic/minimal, common/typical and complete could be selected instead of changing the whole setup? It would help! What answer are you expecting? It's a volunteer project. We make changes as time permits and as people are inclined. We thought the current setup with categories would be an improvement and apparently it wasn't. It never occurred to us that people wouldn't be able to figure out that you could click on things and see packages to install. But, that was the case. Once it became clear that there was a problem and that people didn't like having to select things individually, I would have liked to see an immediate resolution of the problem but it just didn't happen. It's not like I can fire anyone for not improving setup for you. I'm just damn grateful that Robert and others are spending time working on it at all. Anyway, the new, just released, version of setup has some improvements for selecting whole categories. That should make things much easier. We're discussing other alternatives all of the time but the basic problem is that we have a lot of people who just ask aggrieved questions like the above or who repeat the same observations that have been made countless times before, and very few people who are actually willing to help make things better. If you want to contribute (and apparently you do), then setup.exe discussions are happening in the cygwin-apps mailing lists. If you have further questions, you should (after reviewing the mail archives there) send them there. cgf I think the change you're referring to was that we added, at the request of many users, a minimal install. It's based on the debian base category, which does not include bzip2. The default installation is a really basic one and it's looking like we need to change that. Anyway, I'll try to keep in this in mind if we change something in the future that impacts Cygwin/XFree86. It never occurred to me that this would be an issue. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: missing telnet, solution
-Original Message- From: mstucky5 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 10:10 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: missing telnet, solution This whole thread got me thinking about possible ways to avoid this xxx is missing problem... I thought that I'd throw an idea out for discussion... Would it make sense to have setup install a dummy script for some of the common utilities and then overwrite that script with the actual utility if it is selected from the gui as it should be? In debian, there is a package that will do this - I think it that when a binary is not found it queries dpkg to see if a package that can provide it exists. Anyway, I think that an _automated_ approach to this could be quite useful, but not a manual one. (I realise that you didn't imply either, I'm simply getting there first :}). Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime
First I'll answer your question 3. Having defined timezone does not mean it
will work.
#include stdio.h
#include time.h
int main()
{
tzset();
printf(%ld\n, timezone);
printf(%ld\n, _timezone);
return 0;
}
$ gcc -Wall test.c
test.c: In function `main':
test.c:7: warning: long int format, pointer arg (arg 2)
$ ./a
4198632
-28800
Enough? (Not well tested, uh?)
Second, no one should ignore backward compatibility (M$'s success is partly
owing to this, as well as Unix's popularity), as long as it does not violate
the design rules (standards-conformance, etc.). I don't think, say,
respecting the second argument of gettimeofday is a sin; those not wanting
it can simply pass NULL.
There is a SERIOUS misunderstanding about standards conformance here. An
unusable timezone is a violation, but well-behaved ftime and gettimeofday
are NOT.
Just as the morale of network protocol implementation is: Be generous to
accept, and be prudent to send. So I think in programming we also should
make environments (run-times, librabries) as compatible as possible, and
write applications as portable as possible.
A standard should specify what we SHOULD do, but it never restricts what we
COULD do. Not to mention that what I asked for has long been there in the
UNIX tradition already.
As I have said already, unspecified in a standard means the standard does
not say anything about the implementation, and, IMHO, the implementors are
free to choose from the best practices. Better practices mean better
compatibility, don't they?
Summary of my points. Making ftime and gettimeofday get timezone information
is not a violation of any standards, and will make Cygwin only better
(unless someone thinks better compatibility is a sin).
Hope I am clear enough. I am arguing here for a BETTER Cygwin.
Best regards,
Wu Yongwei
--- Original Message from Karsten Fleischer ---
Thank you for your suggestions. The points are:
1) Cygwin did very well, but not now;
That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS.
2) I was not using ftime to get time, but to get timezone information.
OK, another quote from the SUSv3 docs
http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html:
---
FUTURE DIRECTIONS
This function may be withdrawn in a future version.
---
[This wasn't in the SUSv2 docs, though.]
So, _do not_ use this function to get time or timezone information.
3) timezone variable is not usable in Cygwin.
Why not?
In my installation 1.3.10 installation I see this in the time.h header
file:
---
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
---
And _timezone is declared some lines above:
---
extern __IMPORT time_t _timezone;
---
This is not strictly following the SUSv2 or SUSv3 standards, but it
should work.
SUSv2 says:
---
The following are declared as variables:
extern int daylight;
extern long int timezone;
extern char *tzname[];
---
SUSv3 says:
---
The following shall be declared as variables:
extern intdaylight;
extern long timezone;
extern char *tzname[];
---
timezone is a macro on Cygwin, but the typecast is OK.
You can dig through the Cygwin sources and send in a patch to make
Cygwin fully SUS compliant.
So timezone is now not portable. Cygwin broke some unportable code.
It didn't talk about unportable code.
What I was trying to say is, that you wrote code that doesn't follow the
standards and that is likely to break on any other platform.
Read the SUSv2 at the link that Christopher Faylor gave you already.
SUSv3 is quite new, so it's likely that other platforms are not really
compliant to this new standard, yet.
Karsten
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime
When I write new code, _I_ will not use ftime again. In fact, I have fixed my synctime program with an ugly ifndef __CYGWIN__ macro and replaced code using ftime with _timezone (timezone). However, breaking legacy code is not good behaviour for a (runtime) environment. Also, I don't intend my code will run on any platforms. In fact, seldom will any code with a little complexity without real-environment test. I DO want my code to run flawlessly on frequently-used x86 Unix enviroments, Linux, FreeBSD, Cygwin, etc. Sorry that I do not understand your English very well. But I hope I have expressed my meanings. Best regards, Wu Yongwei --- Original Message from Randall R Schulz --- Yongwei, At 18:45 2002-03-25, you wrote: ... Hope I am clear enough. I am arguing here for a BETTER Cygwin. No. You're asking to be let off the hook for either writing intrinsically portable code or of featuring it with conditional compilation directives so that it functions as you want it to on all platforms you want to claim to support. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime (patch included)
OK, here is the patch for src/winsup/cygwin/times.cc:
--- times.cc.oldTue Mar 26 11:36:53 2002
+++ times.ccTue Mar 26 11:53:42 2002
-156,4 +156,5
{
static hires gtod;
+ static tzflag;
LONGLONG now = gtod.usecs (false);
if (now == (LONGLONG) -1)
-162,4 +163,15
tv-tv_sec = now / 100;
tv-tv_usec = now % 100;
+
+ if (tz != NULL)
+{
+ if (!tzflag) {
+tzset();
+tzflag = 1;
+ }
+ tz-tz_minuteswest = _timezone / 60;
+ tz-tz_dsttime = _daylight;
+}
+
return 0;
}
I did not submit a patch because I did not think you will accept it. Writing
the patch itself is easy: it was already there in an old CVS version. Or
almost so. Notice that I do not always call tzset. My previous experience
with MSVC indicates that calling tzset is costly. I am not sure of the case
with Cygwin. However, it is just there for you to review.
Best regards,
Wu Yongwei
--- Original Message from Christopher Faylor ---
On Tue, Mar 26, 2002 at 10:45:32AM +0800, Wu Yongwei wrote:
Hope I am clear enough. I am arguing here for a BETTER Cygwin.
I guess I wasn't clear enough.
SUPPLY A PATCH TO FIX THE BEHAVIOR.
If you want me, or anyone else to fix it, you'll undoubtedly have a long
wait. Especially since you have now polarized me by arguing points when
you could have been investigating the code and supplying a fix.
No arguments in the world work better than an actual patch.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
GLUI/GLUT setup...
Hey, does anyone know a good link for setting up GLUI and GLUT with cygwin? Im having some path problems...probably related to my makefile. If anyone knows something about setting this up, I'd love to hear from you. Thanks, Matt ___ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin1.dll bug in ftime
From: Wu Yongwei [EMAIL PROTECTED] This is from the glibc documentation (is glibc meaningless to the Cygwin project?): I'm not sure what you mean by meaningless, but glibc is of no particular relevance to Cygwin. ... The GNU operating system does not support using struct timezone to represent time zone information; that is an obsolete feature of 4.3 BSD. Instead, use the facilities described in 21.4.8 Functions and Variables for Time Zones. You quote documentation that tells you not to do what you are doing. I do not understand you quite clearly. And I want to emphasize again that IT USED TO WORK! Do I need to write patches so that the code is unpatched? If anything is going to change, somebody has to write patches. If you're the one that wants it to change, it seems reasonable that you should be the one who writes the patches. Also notes the usage of unspecified. Unspecified means the standard does not say anything about the implementation, and, IMHO, the implementors are free to choose the best practices. I think it is obviously a good way to follow BSD. Am I wrong? You're wrong to say that it's obvious. Why is it better to follow BSD than any other version of UNIX? Why is it better to do anything in particular with an obsolete feature that has been deprecated for many many years? Thank you for your suggestions. The points are: 1) Cygwin did very well, but not now; 2) I was not using ftime to get time, but to get timezone information. 3) timezone variable is not usable in Cygwin. So timezone is now not portable. Cygwin broke some unportable code. Is that a surprise? Unportable code, by definition, is likely to break between different releases of an OS, and between different OSes. Instead of spending time complaining here, you'd be better off generating patches to introduce the behaviour you want. Even better, spend the time changing your code to use the standard portable ways of doing what you want to do. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
