Re: [RFU] udunits-2.1.24-1
On Dec 18 22:06, marco atzeri wrote: new upstream release to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/udunits/index.html rm ./index.html \ ./libudunits-devel/index.html \ ./libudunits0/index.html Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] arpack-3.0.1-1
On Dec 18 22:11, marco atzeri wrote: New release from a new upstream team http://forge.scilab.org/index.php/p/arpack-ng/ This project is a joint project between Debian, Octave and Scilab in order to provide a common and maintained version of arpack. Indeed, no single release has been published by Rice university for the last few years and since many software (Octave, Scilab, R, Matlab...) forked it and implemented their own modifications, arpack-ng aims to tackle this by providing a common repository and maintained versions. arpack-ng is replacing arpack in Debian Ubuntu. Fink, Fedora and Redhat are currently doing the same move. to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/index.html rm ./index.html \ ./libarpack-devel/index.html \ ./libarpack0/index.html File list: arpack-3.0.1-1-src.tar.bz2 arpack-3.0.1-1.tar.bz2 libarpack-devel/libarpack-devel-3.0.1-1.tar.bz2 libarpack-devel/setup.hint libarpack0/libarpack0-3.0.1-1.tar.bz2 libarpack0/setup.hint setup.hint Uploaded, but I'm wondering if that package will show up as curr. The version number of the previous package was 96-1, which is bigger than 3.0.1-1 afaics, so upset will probably treat 96-1 as curr and 3.0.1-1 as prev. Can you prepare setup.hint files? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] arpack-3.0.1-1
On 12/19/2011 12:55 PM, Corinna Vinschen wrote: On Dec 18 22:11, marco atzeri wrote: New release from a new upstream team http://forge.scilab.org/index.php/p/arpack-ng/ This project is a joint project between Debian, Octave and Scilab in order to provide a common and maintained version of arpack. Indeed, no single release has been published by Rice university for the last few years and since many software (Octave, Scilab, R, Matlab...) forked it and implemented their own modifications, arpack-ng aims to tackle this by providing a common repository and maintained versions. arpack-ng is replacing arpack in Debian Ubuntu. Fink, Fedora and Redhat are currently doing the same move. to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/index.html rm ./index.html \ ./libarpack-devel/index.html \ ./libarpack0/index.html File list: arpack-3.0.1-1-src.tar.bz2 arpack-3.0.1-1.tar.bz2 libarpack-devel/libarpack-devel-3.0.1-1.tar.bz2 libarpack-devel/setup.hint libarpack0/libarpack0-3.0.1-1.tar.bz2 libarpack0/setup.hint setup.hint Uploaded, but I'm wondering if that package will show up as curr. The version number of the previous package was 96-1, which is bigger than 3.0.1-1 afaics, so upset will probably treat 96-1 as curr and 3.0.1-1 as prev. Can you prepare setup.hint files? Thanks, Corinna done wget -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/setup.hint wget -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/libarpack-devel/setup.hint wget -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/libarpack0/setup.hint Regards Marco
Re: [RFU] arpack-3.0.1-1
On Dec 19 13:32, marco atzeri wrote: On 12/19/2011 12:55 PM, Corinna Vinschen wrote: On Dec 18 22:11, marco atzeri wrote: New release from a new upstream team http://forge.scilab.org/index.php/p/arpack-ng/ This project is a joint project between Debian, Octave and Scilab in order to provide a common and maintained version of arpack. Indeed, no single release has been published by Rice university for the last few years and since many software (Octave, Scilab, R, Matlab...) forked it and implemented their own modifications, arpack-ng aims to tackle this by providing a common repository and maintained versions. arpack-ng is replacing arpack in Debian Ubuntu. Fink, Fedora and Redhat are currently doing the same move. to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/index.html rm ./index.html \ ./libarpack-devel/index.html \ ./libarpack0/index.html File list: arpack-3.0.1-1-src.tar.bz2 arpack-3.0.1-1.tar.bz2 libarpack-devel/libarpack-devel-3.0.1-1.tar.bz2 libarpack-devel/setup.hint libarpack0/libarpack0-3.0.1-1.tar.bz2 libarpack0/setup.hint setup.hint Uploaded, but I'm wondering if that package will show up as curr. The version number of the previous package was 96-1, which is bigger than 3.0.1-1 afaics, so upset will probably treat 96-1 as curr and 3.0.1-1 as prev. Can you prepare setup.hint files? Thanks, Corinna done wget -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/setup.hint wget -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/libarpack-devel/setup.hint wget -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/arpack/libarpack0/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Bug in csih
Hi Chuck,
during some testing I suddenly found that I couldn't start an sshd which
I had just installed as a service. The reason was that the account I
was using for the service didn't have the Logon as service user right.
Which was puzzeling given that csih calls editrights to add this user
right.
It turned out that the following test in cygwin-service-installation-helper.sh
is incorrect (line 2264):
if ! csih_call_winsys32 net localgroup ${admingroup} | /usr/bin/grep -Eiq
^${user}.?$
The problem occurs if the user account is a domain account. In that
case membership in the local administrators group is often only
indirectly given by being the member in a domain group which in turn
is member in the Administrators group. Example:
DOMAIN\user is member of DOMAIN\Domain Admins
DOMAIN\Domain Admins is member of Administrators
However, the `net localgroup' command does not resolve group memberships.
`net localgroup Administrators' on a domain member machine returns:
Alias name Administrators
Comment[...blah...]
Members
---
Administrator
VINSCHEN\Domain Admins
The command completed successfully.
Calling `net localgroup Administrators /domain' isn't sufficient either,
since it also doesn't return indirect memberships.
Therefore I think the test for being a member of the admins group is
invalid and should just go away. The current behaviour is too surprising
in a domain environment.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [RFU] mingw-w64
On 12/19/2011 08:42, Charles Wilson wrote: On 12/17/2011 11:35 PM, JonY wrote: New mingw-w64 build is ready. Remove the oldest in each category, leave pthreads. A user requested a recent bugfix to be propagated. Sorry for the inconvenience, can you remove the recently uploaded headers and crt? Use the following, thanks. https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/mingw64-i686-headers-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/mingw64-i686-runtime-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-i686/mingw64-i686-runtime/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/mingw64-x86_64-headers-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-headers/setup.hint https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4694-1-src.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/mingw64-x86_64-runtime-3.0b_svn4694-1.tar.bz2 https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/mingw64-x86_64/mingw64-x86_64-runtime/setup.hint signature.asc Description: OpenPGP digital signature
Re: RFU: ocaml-3.12.1-1
Damien? Ping? On Dec 15 23:23, Damien Doligez wrote: On 2011-12-15, at 20:21, Corinna Vinschen wrote: If you want them to show up in the changed form, you should make them available for upload. Here they are: wget -x -nH --cut-dirs=2 \ http://gallium.inria.fr/~doligez/cygwin/ocaml/emacs-ocaml/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-base/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-camlp4/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/ocaml-compiler-libs/setup.hint \ http://gallium.inria.fr/~doligez/cygwin/ocaml/setup.hint Did you see Yaakov's mail on the cygwin list: http://cygwin.com/ml/cygwin/2011-12/msg00350.html I guess i'd prefer to pull the packages and wait for new ones, together with the new hint files. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
src/winsup/cygwin ChangeLog dcrt0.cc wincap.cc ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-12-19 12:50:35 Modified files: winsup/cygwin : ChangeLog dcrt0.cc wincap.cc wincap.h wow64.cc wow64.h Log message: * dcrt0.cc (dll_crt0_0): Check for wincap.wow64_has_secondary_stack rather than for wincap.is_wow64. Accommodate name change from wow64_has_64bit_parent to wow64_needs_stack_adjustment. Align comment. (_dll_crt0): Ditto. * wincap.h (wincaps::wow64_has_secondary_stack): New element. * wincap.cc: Implement above element throughout. (wincapc::init): Set wow64_has_secondary_stack to false on non-64 bit systems. * wow64.cc (wow64_needs_stack_adjustment): Rename (hopefully the last time) from wow64_has_64bit_parent. (wow64_eval_expected_main_stack): Fix comment to reflect real life. (wow64_test_for_64bit_parent): Fix comment. * wow64.h (wow64_needs_stack_adjustment): Accommodate new name. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5636r2=1.5637 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dcrt0.cc.diff?cvsroot=srcr1=1.420r2=1.421 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.cc.diff?cvsroot=srcr1=1.119r2=1.120 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.h.diff?cvsroot=srcr1=1.99r2=1.100 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wow64.cc.diff?cvsroot=srcr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wow64.h.diff?cvsroot=srcr1=1.2r2=1.3
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-12-19 17:01:41 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (rename): Fix typo in comment. Fix condition to handle the case oldpath is no .lnk symlink and newpath points to an existing .lnk symlink or .exe file and no explicit .lnk suffix has been given in oldpath. Add a comment to explain. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5637r2=1.5638 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.608r2=1.609
Re: Add support for creating native windows symlinks
On Dec 18 12:16, Russell Davis wrote: Can someone respond to this? If there's a problem with my suggested approach I'd like to know what it is. Let me know if clarification is needed. Thanks... I don't think it's the right approach to let Cygwin create symlinks which are only partially usable in the POSIX environment, even if only after explicitely enabling them(*). I agree with Andy and Daniel that using a special tool like Daniel's winln for this purpose is the way to go. Corinna (*) Actually I wished desparately I hadn't included the winsymlink setting. It seemed such a good idea at the time, but the extra code necessary to support .lnk symlinks transparently is a big mess. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Add support for creating native windows symlinks
I don't think it's the right approach to let Cygwin create symlinks which are only partially usable in the POSIX environment... Huh? I think you're not fully understanding my suggested approach. As I pointed out in my previous message, it should be 100%, fully usable in the POSIX environment. Again: any path that might be problematic as a Win32 path can just be stored as a POSIX path, and would fall into the bucket of works inside cygwin but not outside.
Re: Add support for creating native windows symlinks
On 12/19/11 11:31 AM, Russell Davis wrote: I don't think it's the right approach to let Cygwin create symlinks which are only partially usable in the POSIX environment... Huh? I think you're not fully understanding my suggested approach. As I pointed out in my previous message, it should be 100%, fully usable in the POSIX environment. Again: any path that might be problematic as a Win32 path can just be stored as a POSIX path, and would fall into the bucket of works inside cygwin but not outside. That's only true until the mount table changes. signature.asc Description: OpenPGP digital signature
Re: Add support for creating native windows symlinks
That's only true until the mount table changes. Can you elaborate on that? If I create a symlink pointing to /mnt/foo (and store the actual POSIX path /mnt/foo in the symlink), and the mount table changes, what's the problem?
Re: tetex-tiny bug
Peter Rosin skrev 2011-11-25 16:48: Hi! It's been a couple of years since I fixed this [1] on my old computer, and now I had to fix it on the new one. Can someone please fix the tetex-tiny package? Below is what I did to fix the problem. Cheers, Peter [1] http://www.cygwin.com/ml/cygwin/2006-05/msg00756.html --- /usr/share/texmf/web2c/fmtutil.cnf.cygwin-dist 2005-05-05 20:54:58.00100 +0200 +++ /usr/share/texmf/web2c/fmtutil.cnf 2011-11-25 16:36:48.748662200 +0100 @@ -41,7 +41,7 @@ textex - -translate-file=cp227.tcx tex.ini aleph aleph - *aleph.ini latex pdfetex language.dat-translate-file=cp227.tcx *latex.ini -etex pdfetex language.def-translate-file=cp227.tcx *etex.ini +etex etexlanguage.def-translate-file=cp227.tcx *etex.ini pdftex pdfetex - -translate-file=cp227.tcx *pdftex.ini pdflatex pdfetex language.dat-translate-file=cp227.tcx *pdflatex.ini pdfetexpdfetex language.def -translate-file=cp227.tcx *pdfetex.ini Next victim [1]. This bug continues to waste time. Cheers, Peter [1] http://lists.gnu.org/archive/html/bug-automake/2011-12/msg00051.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.9: dircolors error on WinXP
* Jon Seidel CMC (Sun, 18 Dec 2011 16:39:25 -0800) Running the following: dircolors -b .dircolors dircolors -b .dircolors results in the error: .dircolors:1: invalid line; missing second token eval $(dircolors -b ~/.dir_colors) Thorsten -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
saving list of packages
hi, I need to save the list of installed packages, to: 1) reinstall Cygwin on the same system or 2) made the same custom Cygwin installation on another system Is there an easy method equivalent to the Debian distribution: To save: $ dpkg --get-selections installedPackagesDate.txt To recover: # dpkg --set-selections installedPackagesDate.txt apt-get dselect-upgrade thanks, Valerio -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: saving list of packages
On 12/19/2011 10:45 AM, efa wrote: hi, I need to save the list of installed packages, to: 1) reinstall Cygwin on the same system or 2) made the same custom Cygwin installation on another system Is there an easy method equivalent to the Debian distribution: To save: $ dpkg --get-selections installedPackagesDate.txt To recover: # dpkg --set-selections installedPackagesDate.txt apt-get dselect-upgrade thanks, Valerio 1) cygcheck -c -d|sed -e 1,2d -e 's/ .*$//' installedPackagesDate.txt 2) see ./setup --help at setup -P -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync of windows shortcuts creates foo and foo.lnk - never fully synchronizes
I just tried something different on a hunch. The problem still occurs when this mkshortcut command is replaced by a simple touch winshortcut.lnk. So the problem I'm having seems to be due to the filename extension, not the contents of the file. Files with other extensions work fine. # create a shortcut cd /tmp/A/foo mkshortcut \ --arguments=mintty \ --name=winshortcut \ --workingdir=$HOME \ /bin/run -Fred -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.9/WinXP: dircolors error
Running the following: dircolors -b .dircolors dircolors -b .dircolors results in the error: .dircolors:1: invalid line; missing second token This works just fine on a Win7 installation of the same 1.7.9 version. Couldn't find anything more recent than a 2006 reference to this error in the list archives I did find that modifying and using the Mandrake /etc/DIR_COLORS file as follows: cp /etc/DIR_COLORS ~/.DIR_COLORS dircolors -b ~/.DIR_COLORS works just fine Thanks...jon-- Jon Seidel CMC Effective Decisions... Priceless! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: saving list of packages
From: marco.atz...@gmail.com 2) see ./setup --help at setup -P seems that -P accept one package a time. Example: setup -M -P arj ash atk ... install only arj This is trange as documentation say packages Running the setup.exe for each package, download: - the mirrors.lst - the setup.bz2 once for each run. Not an optimal solution More, the -q option open anyway the install windows on top of other windows and get focus. This is noisy as busy the PC while the installation finish. With -q I cannot get to install a single package, as seems it does not select the dependancies. Work with a single package using -M, but this require user interaction, doing that for hundreds package is not feasible. Suggestions? Valerio -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync of windows shortcuts creates foo and foo.lnk - never fully synchronizes
On Dec 18 11:52, Fred Wheeler wrote: I am seeing strange rsync behavior in cygwin when synchronizing directories that contain windows shortcuts. When a shortcut foo.lnk gets modified, rsync creates both a foo and foo.lnk file in the receiving side. Repeated runs of rsync print output as if the extra file is removed, but it never really is. The test case below demonstrates the problem. cygcheck.out attached. I've been having this problem for a while - maybe a couple of years. # create 2 working directories mkdir /tmp/A mkdir /tmp/B # create a directory to sync mkdir /tmp/A/foo # create a shortcut cd /tmp/A/foo mkshortcut \ --arguments=mintty \ --name=winshortcut \ --workingdir=$HOME \ /bin/run # rsync 'foo' - works fine rsync -rt --itemize-changes --update --delete /tmp/A/foo /tmp/B # 2nd rsync does nothing - as expected rsync -rt --itemize-changes --update --delete /tmp/A/foo /tmp/B # files in each synced directory look fine - same time stamp and size ls -l /tmp/A/foo ls -l /tmp/B/foo # touch the shortcut touch /tmp/A/foo/winshortcut.lnk # here is where the proble first happens I think # rsync 'foo' - appears to work fine rsync -rt --itemize-changes --update --delete /tmp/A/foo /tmp/B Thanks for the report. I see where the problem occurs. It's one of the hoops the rename(2) function jumps through to support .lnk-style symlinks which has a buggy condition. This should be fixed in CVS. If you're not set up to build your own Cygwin, please give the next developer snapshot a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: saving list of packages
On 12/19/2011 10:33 AM, e...@iol.it wrote: From: marco.atz...@gmail.com 2) see ./setup --help at setup -P seems that -P accept one package a time. Example: setup -M -P arj ash atk ... Use commas to separate package names: setup -M -P arg,ash,atk,... -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: saving list of packages
Da: jer...@bopp.net Use commas to separate package names: setup -M -P arg,ash,atk,... working, thanks. This is not documented. Valerio -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.9/WinXP: dircolors error
On Mon, Dec 19, 2011 at 07:55:17AM -0800, Jon Seidel CMC wrote: Running the following: ? dircolors -b .dircolors ? dircolors -b .dircolors results in the error: ? .dircolors:1: invalid line;? missing second token This works just fine on a Win7 installation of the same 1.7.9 version. Couldn't find anything more recent than a 2006 reference to this error in the list archives I did find that modifying and using the Mandrake /etc/DIR_COLORS file as follows: ? cp /etc/DIR_COLORS ~/.DIR_COLORS ? dircolors -b ~/.DIR_COLORS works just fine Thanks...jon-- Jon Seidel CMC Effective Decisions... Priceless! Three separate messages on this subject is two more than adequate, especially when you already received a response. Please stop the spamming. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Sorry people (NOT MY taxonomy!!), but igncr IS flawed
Greetings, Dave Korn! Windows GUI-based archivers are well known for causing this problem. To be fair, you should reduce your reference to WinZIP is known for. At the very least, WinRAR and 7-Zip, both won't try to hold your hand in this case. I don't know about WinACE, though, and I'm not going to check it myself. -- WBR, Andrey Repin (anrdae...@freemail.ru) 19.12.2011, 20:57 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Latest MinGW-w64 crashes while linking
Jon, I just tried the new version of MinGW-w64 without the header update and the compiler is crashing while linking one of our C++ executables. Here's the link command and the error message: i686-w64-mingw32-g++ -o ivl.exe main.o async.o design_dump.o discipline.o dup_expr.o elaborate.o elab_expr.o elaborate_analog.o elab_lval.o elab_net.o elab_scope.o elab_sig.o elab_sig_analog.o emit.o eval.o eval_attrib.o eval_tree.o expr_synth.o functor.o lexor.o lexor_keyword.o link_const.o load_module.o netlist.o netmisc.o net_analog.o net_assign.o net_design.o netenum.o net_event.o net_expr.o net_func.o net_link.o net_modulo.o net_nex_input.o net_nex_output.o net_proc.o net_scope.o net_tran.o net_udp.o pad_to_width.o parse.o parse_misc.o pform.o pform_analog.o pform_disciplines.o pform_dump.o pform_types.o symbol_search.o sync.o sys_funcs.o verinum.o verireal.o target.o Attrib.o HName.o Module.o PDelays.o PEvent.o PExpr.o PGate.o PGenerate.o PScope.o PSpec.o PTask.o PUdp.o PFunction.o PWire.o Statement.o AStatement.o LineInfo.o StringHeap.o cprop.o nodangle.o synth.o synth2.o syn-rules.o t-dll.o t-dll-api.o t-dll-expr.o t-dll-proc.o t-dll-analog.o collect2: ld terminated with signal 11 [Segmentation fault], core dumped Makefile:209: recipe for target `ivl.exe' failed make: *** [ivl.exe] Error 1 This was compiling correctly with the previous version of the compiler, etc. a couple of days ago. I have not tried to revert to the previous version to see if things work again. FYI this is the Icarus Verilog development (master) branch from git, if you want to try this locally. Regards, Cary -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest MinGW-w64 crashes while linking
Actually compiling (with i686-w64-mingw32-gcc) the following simple C program
is also crashing.
int main()
{
return 0;
}
Cary
- Original Message -
From: Cary R.
Jon,
I just tried the new version of MinGW-w64 without the header update and the
compiler is crashing while linking one of our C++ executables.
Here's the link command and the error message:
i686-w64-mingw32-g++ -o ivl.exe main.o async.o design_dump.o discipline.o
dup_expr.o elaborate.o elab_expr.o elaborate_analog.o elab_lval.o elab_net.o
elab_scope.o elab_sig.o elab_sig_analog.o emit.o eval.o eval_attrib.o
eval_tree.o expr_synth.o functor.o lexor.o lexor_keyword.o link_const.o
load_module.o netlist.o netmisc.o net_analog.o net_assign.o net_design.o
netenum.o net_event.o net_expr.o net_func.o net_link.o net_modulo.o
net_nex_input.o net_nex_output.o net_proc.o net_scope.o net_tran.o net_udp.o
pad_to_width.o parse.o parse_misc.o pform.o pform_analog.o pform_disciplines.o
pform_dump.o pform_types.o symbol_search.o sync.o sys_funcs.o verinum.o
verireal.o target.o Attrib.o HName.o Module.o PDelays.o PEvent.o PExpr.o
PGate.o PGenerate.o PScope.o PSpec.o PTask.o PUdp.o PFunction.o PWire.o
Statement.o AStatement.o LineInfo.o StringHeap.o cprop.o nodangle.o synth.o
synth2.o syn-rules.o t-dll.o t-dll-api.o t-dll-expr.o
t-dll-proc.o t-dll-analog.o
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
Makefile:209: recipe for target `ivl.exe' failed
make: *** [ivl.exe] Error 1
This was compiling correctly with the previous version of the compiler, etc. a
couple of days ago. I have not tried to revert to the previous version to see
if things work again.
FYI this is the Icarus Verilog development (master) branch from git, if you
want to try this locally.
Regards,
Cary
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest MinGW-w64 crashes while linking
On 12/20/2011 03:42, Cary R. wrote:
Actually compiling (with i686-w64-mingw32-gcc) the following simple C program
is also crashing.
int main()
{
return 0;
}
Cary
Strange, I have only some vague ideas what went wrong, I will do a
rebuild and some testing.
signature.asc
Description: OpenPGP digital signature
