RE: [ITP] graphviz/libgraphviz4/libgraphviz-devel/graphviz-doc/graphviz-contrib: An open source graph visualization software
Dave Korn wrote on 02 May 2008 10:56: Dr. Volker Zell wrote on 02 May 2008 09:20: Hi I would like to contribute and maintain the 'graphviz/libgraphviz4/libgraphviz-devel/graphviz-doc/graphviz-contrib' packages. Your sense of timing is perfect. I just spent an evening trying to build this myself and finally got going with some half-working crudely limping along static build... For downloading Will test over the weekend. Thanks very much! Well, the packaging looks ok, and the binaries appear to work after a bit of crude smoke-testing, but I can't successfully rebuild from source. I've tried on two different systems now (both fairly up-to-date), and they've both hung up at this stage: - Making all in vmalloc make[3]: Entering directory `/tmp/volker/graphviz/rebuild/graphviz-2.18-1/build/lib/vmalloc' mkdir -p ../../FEATURE /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/iffe - set cc gcc : run /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/lib/vmalloc/fea tures/vmalloc ../../FEATURE/vmalloc - In each case there was a stuck exe running, FALBA2320.exe for one and FUBIK-something-or-other on the other. The stuck exe was using zero cpu and just sitting there indefinitely. Running it manually at the command-line didn't stall. The sh.exe that invoked the iffe script is still alive but also stalled. After killing the exe, the shell wakes up and carries on with the build. The FALBA2320.c test was checking for the presence of strdup and sure enough it doesn't seem to appear in any of the feature test macros in build/FEATURE/vmalloc. cheers, DaveK -- Can't think of a witty .sigline today
Re: [ITP] graphviz/libgraphviz4/libgraphviz-devel/graphviz-doc/graphviz-contrib: An open source graph visualization software
Dave Korn writes: Well, the packaging looks ok, and the binaries appear to work after a bit of crude smoke-testing, but I can't successfully rebuild from source. I've tried on two different systems now (both fairly up-to-date), and they've both hung up at this stage: - Making all in vmalloc make[3]: Entering directory `/tmp/volker/graphviz/rebuild/graphviz-2.18-1/build/lib/vmalloc' mkdir -p ../../FEATURE /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/iffe - set cc gcc : run /tmp/volker/graphviz/rebuild/graphviz-2.18-1/src/graphviz-2.18/lib/vmalloc/fea tures/vmalloc ../../FEATURE/vmalloc - In each case there was a stuck exe running, FALBA2320.exe for one and FUBIK-something-or-other on the other. The stuck exe was using zero cpu and just sitting there indefinitely. Running it manually at the command-line didn't stall. The sh.exe that invoked the iffe script is still alive but also stalled. After killing the exe, the shell wakes up and carries on with the build. The FALBA2320.c test was checking for the presence of strdup and sure enough it doesn't seem to appear in any of the feature test macros in build/FEATURE/vmalloc. Sorry, I'm busy at the moment I can only say it worked for me. I'll check again if I can reproduce. Ciao Volker
setup.exe: Invalid or unsupported tar format
I've built setup.exe from source (updated today), and the ChangeLog says Brian Dessent fixed the Invalid or unsupported tar format problem with empty tar.bz2 files, but I am still seeing the error popup. I have an empty meta-package to pull in other packages copied from one of the _obsolete packages. I understand these are created via 'tar -T /dev/null -cjf foo.tar.bz2' (see http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html), and diff reports the results identical; the file size is the expected 46 bytes. The setup.exe source (install.cc, Installer::installOne) looks like it expects an error peeking from try_decompress in this situation, but running in the debugger shows try_decompress-peek() successfully reading '0'. Note that if you bunzip2 the empty package, you get a 10K tarball which is all zeroes, so success isn't completely unexpected... $ cygcheck -cd | grep 'bzip\|tar\|cygwin' bzip2 1.0.3-2 cygwin 1.5.25-7 mingw-bzip2 1.0.3-2 tar 1.19-1 Am I missing anything? I'm not sure the best way to fix this; the following patch worked, but seems unlikely to actually be correct in all cases. Is an empty tarball the only case where the peek value will be zero? Index: install.cc === RCS file: /cvs/cygwin-apps/setup/install.cc,v retrieving revision 2.83 diff -u -p -w -r2.83 install.cc --- install.cc 9 Apr 2008 02:25:27 - 2.83 +++ install.cc 5 May 2008 20:15:13 - @@ -259,7 +259,7 @@ Installer::installOne (packagemeta pkgm /* Decompression succeeded but we couldn't grok it as a valid tar archive. */ char c; - if (try_decompress-peek (c, 1) 0) + if (try_decompress-peek (c, 1) 0 || !c) // assume 0 indicates empty tarball /* In some cases, maintainers have uploaded bzipped 0-byte files as dummy packages instead of empty tar files. This is common enough that we should not treat this as an -- Bryan Thrall FlightSafety International [EMAIL PROTECTED]
Re: setup.exe: Invalid or unsupported tar format
Thrall, Bryan wrote: I've built setup.exe from source (updated today), and the ChangeLog says Brian Dessent fixed the Invalid or unsupported tar format problem with empty tar.bz2 files, but I am still seeing the error popup. I have an empty meta-package to pull in other packages copied from one of the _obsolete packages. I understand these are created via 'tar -T /dev/null -cjf foo.tar.bz2' (see http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html), and diff reports the results identical; the file size is the expected 46 bytes. That fix was for empty bzipped files, i.e. the result after decompression is a 0 byte file, so it's not exactly relevant to this situation. The setup.exe source (install.cc, Installer::installOne) looks like it expects an error peeking from try_decompress in this situation, but running in the debugger shows try_decompress-peek() successfully reading '0'. Note that if you bunzip2 the empty package, you get a 10K tarball which is all zeroes, so success isn't completely unexpected... This code should not have ever been reached if the file contained a valid tar header, since archive::extract should not have returned NULL in that case. For a valid-yet-empty tar file (i.e. what the 46 byte thing is supposed to be) archive::extract should succeed but the first call to next_file_name will return an empty string. But it seems that tar -T /dev/null doesn't in fact produce anything resembling a valid tar file, it simply spits out 10k of zeros. And I checked all the old existing 46 byte .tar.bz2 files, and they are in fact just 10k of bzipped zeros. Sigh. Why does tar do this? This causes ::extract to return NULL (since it looks nothing like a tar file) but it's also not an empty file, so peek doesn't fail either. And again, to recap: the reason for generating an error instead of silently moving on in this situation was to diagnose the case where the maintainer used a strange tar implementation to create a package -- without the error the package will be silently skipped which is very confusing. But it seems like this nonsense 10k of zeros will have to be special cased in order to be able to detect the desired error case from the bogus error case. In the mean time, I suggest you use a real empty file as workaround (i.e. bzip2 /dev/null file.tar.bz2) as that should correctly be detected as an empty package if you're using the current setup. Brian
RE: setup.exe: Invalid or unsupported tar format
Brian Dessent wrote on Monday, May 05, 2008 4:12 PM: And again, to recap: the reason for generating an error instead of silently moving on in this situation was to diagnose the case where the maintainer used a strange tar implementation to create a package -- without the error the package will be silently skipped which is very confusing. But it seems like this nonsense 10k of zeros will have to be special cased in order to be able to detect the desired error case from the bogus error case. In the mean time, I suggest you use a real empty file as workaround (i.e. bzip2 /dev/null file.tar.bz2) as that should correctly be detected as an empty package if you're using the current setup. Thanks for the explanation. I used 'bzip2 /dev/null file.tar.bz2', generating a 14 byte tar.bz2 file, and setup.exe handles it just fine. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED]
Re: setup.exe: Invalid or unsupported tar format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Brian Dessent on 5/5/2008 3:11 PM: | I have an empty meta-package to pull in other packages copied from one | of the _obsolete packages. I understand these are created via 'tar -T | /dev/null -cjf foo.tar.bz2' (see | http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html), and diff | reports the results identical; the file size is the expected 46 bytes. It sounds like we need to replace all the 46-byte files with 14 byte ones? ~ But the empty file is technically not a valid tar file, since it lacks the required trailing blocks. | | But it seems that tar -T /dev/null doesn't in fact produce anything | resembling a valid tar file, it simply spits out 10k of zeros. Perhaps this is worth a question on the upstream tar list? According to http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html, it looks like a valid tar file can exist without files, but needs 2 blocks of all 0 bytes to identify the end of the tar file. And since the default tar configures with tar options of -b20, I'm actually surprised it's not 20k of NUL bytes (2 blocks * 20 units of 512 per block). You can reduce the size of a valid tarball with 'tar -b1 -c -T /dev/null', but that's still a 1k file of all NULs. | | In the mean time, I suggest you use a real empty file as workaround | (i.e. bzip2 /dev/null file.tar.bz2) as that should correctly be | detected as an empty package if you're using the current setup. By the way, the special 1.7 setup has this error enabled by default, making it report failure on any attempt to install packages like 'gcc' which are empty tarball placeholders with dependencies elsewhere when trying out the 1.7 tree. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgfvuYACgkQ84KuGfSFAYBH+QCfZomHQERLb7wBUUAP7+S26lUL fIEAnR6LS68JtzQOr8hKiDZPgMgUj2c1 =sLs1 -END PGP SIGNATURE-
Rsync
Can someone please tell me how I can get rsync running on my cygwin install? Thanks Ronald W. Finnegan Bioinformaticist, NIMH Laboratory of Neurotoxicology 10 Center Drive Room 3D42 Bethesda, MD 20892-1262 301 594 3607 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Perl IPC::Cmd
I'm using perl 5.8.7 for Solaris perl 5.8.8 for Cygwin perl 5.8.10 for Windows (native) To my surprise, the Cygwin version of Perl does not include the standard module IPC::Cmd, though the other two (in particular, the earlier 5.8.7 Perl) do. Is there a particular reason, why IPC::Cmd is left out from the Cygwin distribution? Ronald -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl IPC::Cmd
- Original Message - From: Ronald Fischer [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Monday, May 05, 2008 8:00 PM Subject: Perl IPC::Cmd I'm using perl 5.8.7 for Solaris perl 5.8.8 for Cygwin perl 5.8.10 for Windows (native) perl 5.8.10 ?? To my surprise, the Cygwin version of Perl does not include the standard module IPC::Cmd, though the other two (in particular, the earlier 5.8.7 Perl) do. Is there a particular reason, why IPC::Cmd is left out from the Cygwin distribution? I don't know. Mind you, they don't need a reason to not include a non-core module - the fact that it's not a core module is, of itself, sufficient reason. With perl 5.10.0, IPC::Cmd became a core module, so *every* build of perl 5.10.0 ought to include that module. Cheers, Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl IPC::Cmd
Sisyphus sisyphus1 at optusnet.com.au writes: I'm using perl 5.8.7 for Solaris perl 5.8.8 for Cygwin perl 5.8.10 for Windows (native) perl 5.8.10 ?? Sorry, I meant 5.10.0 Mind you, they don't need a reason to not include a non-core module - the fact that it's not a core module is, of itself, sufficient reason. I see. I was not aware that this is not a core module. With perl 5.10.0, IPC::Cmd became a core module, so *every* build of perl 5.10.0 ought to include that module. Thanks a lot. Ronald -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Can't set access rights with chmod
Please have a look at the following transscript: $ ls -l x1.pl -rw-r--r-- 1 fischron mkgroup-l-d 104 May 5 15:54 x1.pl $ chmod 0777 x1.pl $ ls -l x1.pl -rw-r--r-- 1 fischron mkgroup-l-d 104 May 5 15:54 x1.pl $ chmod +x x1.pl $ ls -l x1.pl -rw-r--r-- 1 fischron mkgroup-l-d 104 May 5 15:54 x1.pl The same happens when I try other access right combinations. Somehow, the files get access rights when created (typically 0644, sometimes 0755), but I have no way to change the access right afterwards. This happens only on files stored on my networked drive. In the Cygwin FAQ, I found the following hint: The most common case is that your /etc/passwd or /etc/group files are not properly set up. If ls -l shows a group of mkpasswd or mkgroup, you need to run one or both of those commands. Hmmm... my group is not listed as mkgroup, but as the pretty similar mkgroup-l-d. OTOH, chmod works fine on the non-networked drive (/cygdrive/c), and there ls -l shows mkgroup-l-d as well. Also, neither in the man page of mkgroup, nor on the cygwin FAQ, I could find a hint on how to use the mkgroup program to remedy my situation - if this really is the reason for the problem at all. What could I do to get it working? Ronald -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Can't set access rights with chmod (additional info)
Ronald Fischer fischerr.external at infineon.com writes: In addition to what I wrote in the previous posting, I also tried the following: export CYGWIN=smbntsec Now the behaviour changed in that chmod now works well for *new* files created, but for old files I still can't change anything. This time, I get the error message permission denied: $ ls -l x1.pl -rwx--+ 1 fischron 104 May 5 15:54 x1.pl $ chmod ugo+x x1.pl chmod: changing permissions of `x1.pl': Permission denied $ Ronald -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl IPC::Cmd
Ronald Fischer schrieb: Sisyphus sisyphus1 at optusnet.com.au writes: I'm using perl 5.8.7 for Solaris perl 5.8.8 for Cygwin perl 5.8.10 for Windows (native) perl 5.8.10 ?? Sorry, I meant 5.10.0 Mind you, they don't need a reason to not include a non-core module - the fact that it's not a core module is, of itself, sufficient reason. I see. I was not aware that this is not a core module. With perl 5.10.0, IPC::Cmd became a core module, so *every* build of perl 5.10.0 ought to include that module. perl-5.10.0-3 and all subsequent perl 5.10 releases indeed contain IPC::Cmd. Click on [Exp] and install the test release. Release perl-5.10.0-4 is currently in testing and will be uploaded this week. (adds Win32CORE.a) For the current stable perl-5.8.8-4 you have to do cpan IPC::Cmd -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
how to change dir
In bash, how do you change to another directory? I see that the only directory I can go is home (c:\cygwin) I have other physical drives (d:\). How do I go there? Thanks! -- View this message in context: http://www.nabble.com/how-to-change-dir-tp17070344p17070344.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
On Mon, May 5, 2008 at 4:40 PM, bench33 [EMAIL PROTECTED] wrote: In bash, how do you change to another directory? I see that the only directory I can go is home (c:\cygwin) I have other physical drives (d:\). How do I go there? Cygwin apps (including bash) don't understand drive:paths. Use cd /cygdrive/d/ You can let the cygpath utility do the conversion for you: cd $(cygpath 'd:\') -- Mark J. Reed [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
Mark J. Reed wrote: On Mon, May 5, 2008 at 4:40 PM, bench33 [EMAIL PROTECTED] wrote: In bash, how do you change to another directory? I see that the only directory I can go is home (c:\cygwin) I have other physical drives (d:\). How do I go there? Cygwin apps (including bash) don't understand drive:paths. Use cd /cygdrive/d/ You can let the cygpath utility do the conversion for you: cd $(cygpath 'd:\') cd c:/windows works fine, note forward slash -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
Or you can use the Cygwin mount command. It took me several years(!) to realize the power of this utility. You need do it only once because they're permanent until you change them: mount d:\ /d cd /d By the way, c:\cygwin is /. /home is c:\cygwin\home\your_ID -- Lee Maschmeyer Computing Center Services Computing and Information Technology Wayne State University Detroit, Michigan, USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
Lee Maschmeyer wrote: Or you can use the Cygwin mount command. It took me several years(!) to realize the power of this utility. You need do it only once because they're permanent until you change them: cd 'x:\any windows\path will also\work' I do it all the time when switching between a windoze app path and an existant cygwin window. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Newbie needs help using mingw with cygwin
Hello, I am trying to building Lilypond from source using cygwin (Some parts of the lilypond source have to be changed so that is why I can't download the binary :( I am using the configure script supplied with Lilypond. Unfortunately, Lilypond requires GCC 4.0 and above, so I have downloaded a mingw at version 4.1. I have changed my Path Environment variable and the etc/profile file to use the mingw version of GCC. Everything works fine apart from when I run the configure script it is now complaining that it can't find guile and flex. When I don't use mingw, it finds them and only complains about the compiler being less than 4.0. Anyone any ideas what is going on and an idea how to fix it would be lovely. Cheers Mark _ Win Indiana Jones prizes with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl001002ukm/direct/01/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cleanup after failed setup?
Aloha, Periodically, when I try to update Cygwin with setup.exe the process hangs and requires a `cancel' to stop. Often after this setup crashes on subsequent runs after all the various startup questions and leaves nothing in setup.log or setup.log.full to debug with. Is there a way to fix this without a complete uninstall? (setup.exe version 2.573.2.2 and quite a few previous. A number of different machines running XP and Win2k.) Thanks, Richard -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
FW: How to manipulate access control lists (ACL)?
I put a query on unix.com and they pointed me to http://linux.about.com/library/cmd/blcmdl5_acl.htm . I don't understand this link: is it describing a bash command? At bash I type info acl and man acl but I cannot find any description of a bash command for adding an ACL to a file. Can I do this from cygwin bash? Thanks! Siegfried -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FW: How to manipulate access control lists (ACL)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Siegfried Heintze (Aditi) wrote: | I put a query on unix.com and they pointed me to | http://linux.about.com/library/cmd/blcmdl5_acl.htm . | | I don't understand this link: is it describing a bash command? No, it's not. It describes the format of the lists and how ACLs work. | At bash I type info acl and man acl but I cannot find any | description of a bash command for adding an ACL to a file. Can I | do this from cygwin bash? getfacl(1) and setfacl(1). Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgfsyUACgkQpiWmPGlmQSOgngCgwC0pKiomcmq2zz+8bpVjc0xF m04AoKaDGGjVAWLdnfIBFoa/LTzkG/gw =fX/D -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: FW: How to manipulate access control lists (ACL)?
On Mon, May 5, 2008 at 9:23 PM, Yaakov (Cygwin Ports) | At bash I type info acl and man acl but I cannot find any | description of a bash command for adding an ACL to a file. Can I | do this from cygwin bash? getfacl(1) and setfacl(1). FWIW, can also run the Windows commands (e.g. cacls) from bash if you put the appropriate directory in your $PATH. -- Mark J. Reed [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Newbie needs help using mingw with cygwin
Mark Hanlon wrote: Hello, I am trying to building Lilypond from source using cygwin (Some parts of the lilypond source have to be changed so that is why I can't download the binary :( I am using the configure script supplied with Lilypond. Unfortunately, Lilypond requires GCC 4.0 and above, so I have downloaded a mingw at version 4.1. I have changed my Path Environment variable and the etc/profile file to use the mingw version of GCC. Everything works fine apart from when I run the configure script it is now complaining that it can't find guile and flex. When I don't use mingw, it finds them and only complains about the compiler being less than 4.0. Anyone any ideas what is going on and an idea how to fix it would be lovely. You're asking for mingw to work as a cygwin compiler, but the run-time libraries are incompatible. I'd bet on installing a recent gcc build for cygwin. If you don't need g++, you could take pre-built binaries from gfortran wiki. Doesn't the lilypond maintainer have instructions? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
Ok, so I was totally wrong about Windows paths not working. I guess the OP was running into quoting issues. So the answer: put single quotes around the pathname when using it in bash. On 5/5/08, Lee D. Rothstein [EMAIL PROTECTED] wrote: Lee Maschmeyer wrote: Or you can use the Cygwin mount command. It took me several years(!) to realize the power of this utility. You need do it only once because they're permanent until you change them: cd 'x:\any windows\path will also\work' I do it all the time when switching between a windoze app path and an existant cygwin window. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
thank you so much everyone!!! -- View this message in context: http://www.nabble.com/how-to-change-dir-tp17070344p17071546.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how to change dir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lee D. Rothstein wrote: | cd 'x:\any windows\path will also\work' Or you can escape the backslashes and spaces. e.g.: cd x:\\any\ windows\\path\ will\ also\\work Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgf1lMACgkQpiWmPGlmQSMn8gCfY1rVvzkwyf3LIgmL8p1vOuvw SL4AoPu96fV8EdFW7NnDgqAKOsASJKYK =ceZr -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yaakov (Cygwin Ports) wrote: | This package had AM_GNU_GETTEXT in configure.ac without any arguments | nor AM_GNU_GETTEXT_VERSION. autoreconf decided not using Gettext[1] | and didn't install config.rpath[2]. But AC_LIB_RPATH (from the included | gettext-0.11.2 lib-link.m4) was called; while nothing happened due to | the missing config.rpath, it then defined libext=$acl_cv_libext, which | had never been defined. This empty $libext clobbered that of libtool. This is worse than I originally thought. AM_ICONV also calls AC_LIB_RPATH. I got yet another broken libtool, this time with a unsupported hardcode properties error. Here's why: a different package shipped with a 0-byte config.rpath, which obviously didn't do much. But the real problem is with AC_LIB_RPATH itself. In 0.15, it defines the following: wl=$acl_cv_wl libext=$acl_cv_libext shlibext=$acl_cv_shlibext hardcode_libdir_flag_spec=$acl_cv_hardcode_libdir_flag_spec hardcode_libdir_separator=$acl_cv_hardcode_libdir_separator hardcode_direct=$acl_cv_hardcode_direct hardcode_minus_L=$acl_cv_hardcode_minus_L Except for shlibext, all of the above variables can conflict with variables by the same name in libtool. If the config.rpath call doesn't succeed (usually because it's nonexistant), all of these variables are blank, which then clobbers the variables previously set by libtool. While each of these cases should be fixed within the package, I think the only *safe* answer is that: 1) libtool MUST protect its variables; 2) AC_LIB_RPATH should check that there was actually a result from config.rpath before proceeding. (And I would still patch shrext=dll.a as you suggested.) One thing I don't understand: if you call LT_OUTPUT (which generates an unclobbered libtool), isn't 'config.status libtool' supposed to use config.lt to generate libtool, which should avoid these problems? | [2] lib-link.m4 0.15 adds a line telling automake = 1.10 that | config.rpath is required, but this package was using 1.9. In any case, | this macro was from 0.11.2, which preceded automake-1.10. Lots of good that did me here, as the file was present but blank. :-( Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgf6JcACgkQpiWmPGlmQSMolwCgiEIu5ZMjD1dulA+6uix60pTm 2j0An3ogNN7lFh0Sw8rvtmwJFrOtWO+I =DHry -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
