I'm sure the answer to this already exists, but
googling didn't turn anything up, and I'm not the
GCC expert I wish I were. :-(
I'm using "gcc -MM" to build make dependencies. It
used to skip anything included in <>, but now it
uses some other mechanism to decide which headers
are "system". This d
I wrote:
> Meanwhile, I'm looking for a workaround (-I- didn't
> help). I'll poke around other lists, but I'd bet
> somebody's already run into this with Cygwin. "Piss
> off but have a nice day anyway" is an acceptible
> response, but any web/FAQ/message/etc. references
> would be highly appreciate
Randall R Schulz wrote:
> Obligatory disclaimer: I ANAL. You?
You'd better make that IANASCJ
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://
I've updated the version of SWIG to 1.3.19-1. Tarballs should
be available on the Cygwin mirrors shortly.
As per the SWIG web page (http://www.swig.org):
SWIG (Simplified Wrapper Interface Generator) is a software
development tool that connects programs written in C and C++
with a variety o
Krzysztof Duleba wrote:
> I wanted to test some of my linux assembler code on my
> Windows-Cygwin box.
> Is it possible at all?
I don't know about using BIOS calls, etc., but I've
assembled and linked a few NASM assembly functions.
I didn't use ELF format, though. There's a gnuwin32
format that w
Krzysztof Duleba wrote:
> What about Linux syscalls? Will Cygwin emulation layer match
> it?
I just Googled "int 0x80". So THAT'S what you're
trying to do. :-)
No, I think your experiment shows that Cygwin is
not emulating Linux syscalls at that level. Nor
would I have expected it to.
On the ot
Krzysztof Duleba wrote:
> Why not? c code, translated to asm with -c -S on linux box,
> can be later compiled and linked with Cygwin's gcc and works
> fine. As you see, I have a good reason to believe that nasm's
> int 0x80 will work too. So maybe I should simply look for a
> nasm -> gcc's assembl
Krzysztof Duleba wrote:
> I gave up. I see no chance to compile Line at all. And even
> if I succeed, Line will probably bail out.
Yes, I noticed that LINE was a dead project after you
mentioned that you were trying to recompile it. I was
hoping you would have success, since it sounded like
a wor
G.-B. Hauck wrote:
> g++ -mwindows -mno-cygwin -o test.exe test.o -L./ -lmaintest
>
> /usr/lib/gcc-lib/i686-pc-mingw32/3.3.1/../../../../i686-pc-min
> gw32/lib/libmingw32.a(main.o)(.text+0x9b):main.c: undefined
> reference to [EMAIL PROTECTED]'
> collect2: ld returned 1 exit status
This isn't sp
Phil Crescioli wrote:
> [...] For now I'm just curious. I have other pressing Cygwin
> things to dive into before the gvim thing, but when the time
> is right, I will gladly contribute to the gvim deal since I
> am a very content Cygwin user :)
It's been a while since I've done it, but gvim use
I started using zsh about 10 months ago myself. Now I can have
my favorite ksh feature (two argument cd) as well as all the
things I like in BASH. But I digress...
I edited my /etc/profile, replacing bash with zsh, though that
of course doesn't help me start ZSH from Windows.
To get that, I copie
Corinna Vinschen wrote:
> You're doing something differently here, perhaps in vim itself.
For example, the following?
:set nobackup nowritebackup
If you disable both backup and writebackup, it leaves the file
name unchanged when you write to it. So there's a workaround if
you don't care about th
Alireza Ghasemi wrote:
> I have the same problem about ls too. Do they
> ever support syntax highlighting ?
For ls, this might work for you:
alias ls='ls -color=auto '
-gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.ht
Eric Blake wrote:
> Actually, a better spelling would be
> alias ls='ls --color=auto'
Oops, I should have used cut and paste rather than
typing it. I meant this of course:
alias ls='ls --color=auto '
> The use of a trailing space in the alias controls
> whether the next word on the command lin
Eric Blake wrote:
> Wrong again - alias expansion in bash starts ONLY at the
> first word, and only progresses on to the next word if
> the current alias expansion ended in a space.
I stand corrected. In the first job where I used
ksh, they had set up aliases for everything with
the spaces at the
Chris Taylor wrote:
> Yes. Don't use the cmd-based cygwin interface.
> Use rxvt.
Agreed. However, expect the occasional surprise when
running non-Cygwin console binaries since they won't
recognize that they are running on a terminal. I use
a Tcl-based debugger at work, and when running it in
Win32
Andrew DeFaria wrote:
>> Rxvt.font1: "Lucida Console-10"
>> Rxvt.font2: "Lucida Console-13"
>> Rxvt.font: "Lucida Console-16"
...
> What do these do?
font sets the default font. The others set alternate fonts like the
ones you normally get on the right mouse button in xterms. At least
in my config
Andrew DeFaria wrote:
> Too many things? Other than I/O (which I agree is important)
> of certain Windows only programs what else does rxvt do wrong?
This is getting a bit off-topic, but one thing that
bothers me is "normal" resizing under Windows. I'd
rather it behave like it does under X (and co
Igor Pechtchanski wrote:
> On Tue, 6 Dec 2005, Tomasz Chmielewski wrote:
>> But I don't really know where to start (which tool should I use for
>> it?)
>
> Umm, "crypt"?
Or better yet, ccrypt. Check its manpage.
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem re
Ehud Karni wrote:
> [I think this discussion is off topic for cygwin]
Agreed, which is why I didn't elucidate earlier. If I
were inclined to do something like your second script
and override normal passphrase security, I'd probably
use another mechanism (maybe an environment variable?)
to avoid th
Dave Korn wrote:
> I generally use a line like this:
> alias cls='cmd -c cls'
For me, that has to read 'cmd /c cls' or it doesn't work. :-P
This was mildly annoying me for a while as well. I finally
broke down and took a look into it. It looks like the ESC c
(reset terminal) control works und
Maurício wrote:
>I've been using rxvt, as recommended by chere man page. I have a
> problem: in some non-cygwin console programs (ghci, the Haskell
> interpreter, and others) the up arrow key doesn't work as expected.
This has been discussed here previously. Non-cygwin programs
don't recognize
Igor Peshansky wrote:
> YA typo. The above should read:
>
> alias cs='echo -ne "\ec"'
Yes, this is what you need to do under BASH. I thought
I had verified it there, but I guess I wasn't getting
what I thought I was getting. (I mostly use ZSH--at
least I knew better than to write "print -n $'\ec
Igor Peshansky wrote:
> Yes, but "printf '\ec'" works ju-ust fine in bash... :-)
Even better. That works unchanged in both bash and zsh.
> Do you set your TERM to "rxvt" or "xterm"? The control sequence in
> the terminfo database may be wrong if you don't use the native "rxvt"
> terminal setting
If you need to find out what gcc is targeting, perhaps you should
use "-dumpmachine" instead.
$ gcc -dumpmachine
i686-pc-cygwin
$ gcc -dumpmachine -mno-cygwin
i686-pc-mingw32
Lloyd Wood wrote:
> cygming, not cygwin? ('ming' is a strong insult in the UK. I get
> the impression the writer doesn
mwoehlke wrote:
> (Speaking of case sensitivity, is it a Windows limitation that Cygwin
> can't do this? I'm pretty sure it isn't an NTFS limitation,
> as Interix has true case-sensitivity.)
You are right--NTFS can handle it, although the normal Windows
file and directory handling routines cannot.
Huw wrote:
> The first issue was an omission of #defines. IPv6 isn't a
> necessity for the UNP source, I believe.
I'd say the real issue is a failure to protect the use of
AF_INET6. You'll notice that it's protected by an #ifdef
earlier.
> The next issue I have is:
>
> mcast_leave.c: In functio
Brad Krane wrote:
> I'm trying to compile the scientific package CMBFAST-4.5.1 in the
> cygwin environment using g77. I get the following error...
>
> f77 -O2 -c -o jlgen.o jlgen.F
> jlgen.F: In program `jlgen':
> jlgen.F:14:
> include 'cmbfast.inc'
> ^
> Unable to open INCLUDE f
Billinghurst, David (CALCRTS) wrote:
> This is not really a cygwin problem.
I guess you didn't see my post--if the compiler should be
able to find an include file in the same directory as the
source file (and/or the current directory, since they are
the same in this case), then it is a cygwin prob
Dave Korn wrote:
> We *need* to see the actual command line.
That was in the original post (sorry, I should have made
sure it was included in the text when I CC'ed you...):
> f77 -O2 -c -o jlgen.o jlgen.F
The command was being executed from the same directory
as jlgen.F, which also contains
Igor Peshansky wrote:
> Doesn't foo.F represent a FORTRAN file that needs to be preprocessed
> by the C preprocessor? Changing foo.F to contain
>
> #include "foo.inc"
>
> makes it work for me.
That is no doubt the difference. As I said, I don't use
FORTRAN enough to know what others would expec
Presumably somebody from RedHat has already contacted the ERightSoft
folks for illegally distributing cygwin1.dll & cygz.dll without the
source (as part of their SUPER package).
However, they also install those files into /WINDOWS/SYSTEM32 *and*
mark them both SYSTEM and HIDDEN. This may be the ca
Dave Korn wrote:
> Should it perhaps say
>
> > for d in /usr/info /usr/share/info ${INFOPATH} do
Aha! So THAT'S what happened to my info directory! I
hadn't really looked into it, since usually I just
type "info bletch" anyway. I ran a modified version
of that script and it's back to normal now.
I've had some luck with the ECOS version. You can find
it at http://sources.redhat.com/ecos/
-Jerry
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: h
> [ ] Offended. Think about the children!
> [ ] Not offended. Stop bothering me with your Puritanical values.
> [ ] Don't care. Can we go back to talking about how
> negative this list is now?
> [x] Not offended. Clean it up anyway. It's unprofessional
> in the extreme and can only r
OK, anybody still reading this thread probably already knows how to
do this, but just in case, here's what you need to do to clean up
your fortune files (other than just deleting them):
First, make sure you have the tools you need and double-check that
the "offensive" files are in plaintext:
$ ls
Matt Olson wrote:
> I've narrowed my problems down to a relatively small test case:
[...]
> Makefile:
[...]
> LINKFLAGS = -g -L/lib/mingw -mwindows -mno-cygwin
> LIBS = -lmingw32
>
> foo: foo.o
> gcc $(LINKFLAGS) -o foo foo.o $(LIBS)
[...]
> Compiler output:
> $ make
> gcc -g -L. -L/h
Matt Olson wrote:
> Unfortunately, while "compile .o files with -mno-cygwin" fixes my toy
> example, it doesn't help the real code I'm trying to build:
[...]
> If the problem is object files being compiled without -mno-cygwin and
> linked with it, do I need to make sure that all of the (static?)
>
Anh Vo wrote:
> I successfully built it for three languages Ada, C, C++ with
> configured as --enable-languages=ada,c,c++
> --enable-threads=gnat. A number of Ada Conformance Assessment
> Test Suite (ACATS) failed. Further testing reveals that the
> Ada runtime tasking support was not included
Karl M wrote:
>>> While looking at my PATH environment variable (in response to the
>>> recent postings about sshd and environment variables), I noticed
>>> that "." was included.
>>>
>>> It was caused by a double ; ( a ";;" sequence) in my PATH as
>>> defined in the Windows XP My Computer Proper
Christopher Faylor wrote:
> Keith, you don't have a complete reference for the Nt functions do
you?
Keith Moore wrote:
> So, unfortunately, I don't have a complete reference, but there are
> enough "islands of information" around for us to piece together
> everything we need.
Have you looked at
Corinna Vinschen wrote:
> Not that I know of. We're discussing to convert Cygwin's path
> handling to use Unicode for a while now, but it will take time.
> Don't expect this any time soon.
I've been off of the developer list for a while now, and
now the archives are subscriber only. :-(
How are
I wrote:
>> However, it was NTFS-specific and Cygwin went a different
>> route (which has path length limitations, but I digress).
Christopher Faylor wrote:
> And, Joshua could I get a FAQ entry about this, too? This
> has got to be at least the fifth time that someone has felt
> compelled to mak
> Of course we would be glad to have more people working on
> the DLL (and sign the copyright assignment, sigh),
Yes, the assignment was/is a hurdle for me. It turns out to
be much easier to release something into the public domain
(at least at my company), thus my approach. I had actually
made so
Christopher Faylor wrote:
> But releasing something to the public domain doesn't help
> Cygwin. [...] The problem is that you still have to verify
> that the sources are truly public domain and how do you do
> that without getting a disclaimer from a person's employer?
[...]
> I truly hate all of t
I wrote:
>> [...] If a disclaimer is all that you want, I'm sure you/I can get
>> it. In fact, as long as they know about the uncopyrighted code and
>> don't do anything about it, they've given up rights to it.
Christopher Faylor wrote:
> And you prove that they don't know anything about it by...
Peter Waltman wrote:
>> since I used cygwin to implement my masters project (which I'm not
>> getting into publishable form),
Arturus Magi wrote:
> Also, as a note: submitting a masters project may still be considered
> distribution. You may want to solicit advice from a legal authority,
> if p
Richard Heintze wrote:
> I explicitly downloaded insight seperately and had
> troubles with that too, see my earler post. (gdb.exe
> started the GUI interface, but it could not load the
> source code file -- something to do with stat failing.
> chmod 777 test.c did not help).
You shouldn't have to
On Wednesday, July 28, Scott Evans asked:
> Has anyone successfully ported sz/rz to Cygwin?
I searched earlier posts, and it is clear that it had been
done. So I tried grabbing rzsz.sip from www.omen.com and
building it. No problem. Just modify the makefile to add
.exe to the executable names when
Christopher Faylor wrote:
>>> semaphore::_trywait doesn't have anything to do with pthread
>>> mutexes, AFAIK.
Douglas Philips wrote:
>> The real issue is that Python broke with 1.5.18, either because of
>> the pthread change or not. Be that as it may, should I report this
>> bug in another forum?
Christopher Faylor wrote:
> I've mentioned this many times before (and suspect that
> someone else is frantically typing this in right now) but
> mounting directories which contain executable files with
> the -X option makes things a little faster for cygwin:
>
> mount -f -b -X c:/cygwin/bin /bi
Anh Vo wrote:
> If you need both Ada compiler with run-time support and cygwin, do
> the following.
...
> 3. Unzip them in cygwin installed directory. Remember to keep
> the directory structure intact when Unzipping. In addition,
> select over all when prompted by WinZip.
This sounds dangerous to
I wrote:
>> 3. Unzip them in cygwin installed directory. Remember to keep
>> the directory structure intact when Unzipping. In addition,
>> select over all when prompted by WinZip.
>
> This sounds dangerous to me.
Anh Vo wrote:
> It is not all. What it does is to replace the Ada compiler
> (GNAT)
Eric Blake wrote:
> Your situation isn't normal because you didn't stop all cygwin
> services. While the idea has been tossed around on this list
> that it would be nice if setup.exe could stop services for you,
> to date, it does not. Therefore, IT IS UP TO YOU to stop services
> beforehand.
Th
Eric Blake wrote:
> I believe you are referring to the recent question about whether
> cygwin services must be stopped during a WINDOWS upgrade,
My mistake. Thanks for the script.
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/pro
Eric Blake wrote:
> Setup requires a reboot only when Windows reports that a file that was
> being replaced was in use at the time. Therefore, if setup requires a
> reboot, then you didn't properly shut down all cygwin services,
shells,
> and apps.
Probably true 99.9% of the time, although couldn
Shankar Unni wrote:
> But I think it's worth mentioning that 6.3 doesn't do this (change the
> case of the name when writing back). It overwrites the old file when
> writing back, thus preserving its case.
More to the point, the windows version of vim 6.4 doesn't do
this, either. So there is some
Doug Irwin wrote:
> One would expect a "read -r fs t2 t3" to process this without
> attempting to expand slashes. But I can't seem to get this bit
> working... And I can't seem to find any doco on doing that in Cygwin.
>
> I've attached the files I am testing with in the hope that someone
> can h
I wrote:
> This seems to be particularly tied to ksh, and specifically
> when you use "<" to redirect a file. If you simply pipe the
> output of grep to the while loop, it works. Interestingly,
> sh, bash, and zsh all give the behavior you were expecting.
I couldn't resist trying it out on my Linu
Fabrizio Salvatore wrote:
> C:\cygwin\bin\rxvt.exe -fn 7x14 -g 120x24 -si -sk -sb -sl 1000 -fg
> black -bg white -T "cygwin terminal Window" -e /usr/bin/tcsh -l
In case you didn't know, if you some settings most of the time, you
can specify them in ~/.Xdefaults (even if you're not running X). For
I recently ran into a problem where DLL error messages were
apparently suppressed under zsh/RXVT though they appeared
under bash/CONSOLE.
I was trying to build Subversion 1.4.0, and it at one point
configure runs the following command:
ruby -r mkmf -e 'exit(have_func("rb_hash_foreach") ? 0 : 1)
Shankar Unni wrote:
> Before sending your cygcheck.out, try checking the archives.
> This problem was talked about a couple of months ago.
Thanks for the reference. The problem I reported (check the OP)
may be related but isn't exactly the same. AFAICT, suppression
of those DLL error messages shou
Coatimundi wrote:
> If paths are included in the archive (which is typical for
> libs created by Visual Studio), then ar may in some cases
> claim that members (displayed with 'ar t') do not exist
> when doing "ar x lib.a {object}" either by path/name.obj
> or just name.obj.
I think you need to us
Coatimundi wrote:
> Thank you for bringing this up. I forgot to mention (a sure
> sign that my multitasking scaling is rolling over) that I also
> tried the P option.
> While this usually works, I found cases where it did not.
[...]
> Since I see nothing wrong with the source and I am short on
>
Gary R. Van Sickle wrote:
> At the risk of being over-obvious, Linux users... use Linux. In such
> an insular environment, perhaps they have the luxury of only using
> the One True Text File Format (whatever that is).
We're you the one who brought up Unicode earlier? Besides,
there are numerous si
Has anybody successfully built subversion 1.4 (or alternately,
is a release planned soon)? It didn't build OOTB for me, and
I'd rather not duplicate effort.
gsw
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation:
Christopher Faylor wrote:
> If 'ar' insists on backslash separators that is surely a bug.
You may be right, but please stop calling me Shirley. :-)
Larry Hall (Cygwin) wrote:
> Why is that? If 'LIB.EXE' will work with either and 'ar' as a Cygwin
> app prefers '/', why would working with a .lib p
Christopher Faylor wrote:
> The dilemma here is that I read other mailing lists besides
> cygwin where people are trying to use Cygwin but are close
> to giving up because it is so slow. So, making bash faster
> for people who are using it correctly is very desirable.
Which is why we need to get
David Rothenberger wrote:
> I successfully built it with the attached patch. I haven't
> actually used it yet, since some other tools I use don't
> yet support 1.4, but it passed all tests except the ruby
> tests.
Thanks. I'll give it a try. I meanwhile found an earlier post
that recommended "./co
Christopher Faylor wrote:
> You haven't been paying attention, it seems.
>
> We've already been over this ground. The performance impact
> for turning on bash's automatic CRLF handling is profound.
> That's why we're here.
I guess WJM around here. :-) But perhaps I've been paying more
attention
Christopher Faylor wrote:
> When I was maintaining cygwin's gcc, I often thought about eliminating
> -mno-cygwin and just providing a pure mingw cross compiler in the
> distribution.
I completely agree. Anybody depending on -mno-cygwin can create
their own shell wrapper. I personally don't care so
David Bear wrote:
> I would like to have used something like
>
> cd $USERPROFILE
>
> in a bash script but since windows insists on putting spaces in
> names, this seems impossible.
You might be happier writing your scripts in zsh:
bash% cd;pwd
/home/gsw
bash% export SP="silly path"
bash% mkd
[EMAIL PROTECTED] wrote:
> I am dealing with DOS text files and need to output DOS text files.
[...]
> I found dos2unix, but I do not know how to properly implement it. The
> following Bash code is a work-in- progress. Please let me know if a
more
> efficient approach exists.
>
> while read line
Dave Korn wrote:
> Hear, hear. I don't think anything so drastic as this should be
attempted
> without a deprecation period of a year or so for the old behaviour.
And in
> fact I think it would probably transpire to be a serious limitation on
the
> utility of cygwin. Remember, if you just want
Brian Dessent wrote:
> With that out of the way, it's possible to get -mno-cygwin working
with gcc4
> just fine, it shouldn't take any patches. You'll of course have to
build gcc
> again as the MinGW version, and set up some symlinks. See the
postinstall of
> the gcc package for details.
On a re
Brian Dessent wrote:
> The idea behind texinfo is a format-independent way of writing
> documentation. 'info' is just one of a million ways to view this same
> documentation. [...]
Yes, especially for make, I've found the info files to be the best
reference, and they're easily navigable. I'm in t
Christopher Faylor wrote:
> Has anyone used this?
> http://en.poderosa.org/
Looks interesting. Too bad they don't provide console emulation
to Windows.
BTW, I noticed that they include a binary version of cygterm.exe
(in Protocols/Cygterm), which links cygwin1.dll. I didn't see a
link to the Cygw
Jim Kleckner wrote:
> Dave Korn wrote:
[...]
>> I'm adding code to cygcheck to detect whether any of the software
that has
>> been known at some time to cause these kinds of problems are
installed on
>> the target system being cygchecked.
[...]
> Do you think a "tester" for API sanity is possible?
Brian Dessent wrote:
>> $ cd $ttt
>> bash: cd: /cygdrive/c/Program: No such file or directory
>
> Yes, that's wrong. [...] It's got nothing to do with
> cygpath and everything to do with proper portable scripting practice.
Quite true. When you're using bash or sh, you must *quote
your arguments*
As a long-time Cygwin user, I can say that I would very much
appreciate as much information as possible about "known good"
and "known bad" antivirus, firewall, and anti-spyware tools or
combinations thereof, including what Windows version was used,
what special steps needed to be taken, etc.
The p
80 matches
Mail list logo
