Hi David,
On Oct 22 18:19, David Bean wrote:
> Hello Corrina,
s/rrin/rinn/ ;)
>> From: Corinna Vinschen
>> Hi David,
>>
>> On Oct 22 15:56, David Bean wrote:
>> > Good Day,
>> >
>> > I have been working on porting Samba 4.11 to Cygwin for a few days
>> > and ran into an odd issue. Samba configu
@cygwin.com
Subject: Re: Possible bug retrieving IfIndex in newlib - winsup/cygwin/net.cc
Hi David,
On Oct 22 15:56, David Bean wrote:
> Good Day,
>
> I have been working on porting Samba 4.11 to Cygwin for a few days and ran
> into an odd issue. Samba configures its interfaces in s
Hi David,
On Oct 22 15:56, David Bean wrote:
> Good Day,
>
> I have been working on porting Samba 4.11 to Cygwin for a few days and ran
> into an odd issue. Samba configures its interfaces in several steps, but it
> relies pretty heavily on getting information from the interface structures
> p
Greetings, cyg Simple!
> On 3/24/2016 11:43 AM, Dirk Fassbender wrote:
>> Am 24.03.2016 um 15:12 schrieb Unknown Sender:
>>> I noticed this bug for the first time today on a computer that has the
>>> computer name "-" (dash).
>>>
>>> During ssh-host-config:
>>> *** Query: Do you want to use a diff
On Thu, Mar 24, 2016 at 5:45 PM, cyg Simple wrote:
> > the computer name "-" (dash) is illegal in the internet.
>
> Uh, that isn't true.
Yes, it is true.
> > See
> > https://en.wikipedia.org/wiki/Hostname
> > for a start about host name definitions.
> >
>
> From this reference:
> "The Internet st
On 24/03/2016 22:45, cyg Simple wrote:
On 3/24/2016 11:43 AM, Dirk Fassbender wrote:
Am 24.03.2016 um 15:12 schrieb Unknown Sender:
I noticed this bug for the first time today on a computer that has the
computer name "-" (dash).
See
https://en.wikipedia.org/wiki/Hostname
for a start about h
On 3/24/2016 11:43 AM, Dirk Fassbender wrote:
> Am 24.03.2016 um 15:12 schrieb Unknown Sender:
>> I noticed this bug for the first time today on a computer that has the
>> computer name "-" (dash).
>>
>> During ssh-host-config:
>> *** Query: Do you want to use a different name? (yes/no) no
>> /usr/
Am 24.03.2016 um 15:12 schrieb Unknown Sender:
I noticed this bug for the first time today on a computer that has the computer name
"-" (dash).
During ssh-host-config:
*** Query: Do you want to use a different name? (yes/no) no
/usr/bin/getent: invalid option -- '+'
Try `getent --help' or `gete
Greetings, Dave Kilroy!
> -1 mode fails because fish would prefer cygpath was run on the argument
> first. I'm not sure why this works in bash.
Because bash know what is going on. In fact, many cygwin tools recognize
native paths.
> I'll try put together a fix for the latter issue, but it may be
On 10/04/2014 11:06, Ronald Fischer wrote:
I've had more time to look around. If you add the following to the file
~/.config/fish/config.fish (create it if you haven't already got one),
then things should work as intended:
if status --is-login
set PATH /usr/local/bin /usr/bin $PATH
end
> I've had more time to look around. If you add the following to the file
> ~/.config/fish/config.fish (create it if you haven't already got one),
> then things should work as intended:
>
> if status --is-login
> set PATH /usr/local/bin /usr/bin $PATH
> end
>
> Alternatively drop it in th
> I've had more time to look around. If you add the following to the file
> ~/.config/fish/config.fish (create it if you haven't already got one),
> then things should work as intended:
>
> if status --is-login
> set PATH /usr/local/bin /usr/bin $PATH
> end
>
> Alternatively drop it in th
On Tue, Apr 8, 2014, at 0:35, Dave Kilroy wrote:
> On 07/04/2014 13:02, Ronald Fischer wrote:
> > I have installed fish 2.1.0. Works fine, when invoking a new fish shell
> > manually.
> >
> > However, when doing a
> >
> > chere -ifcm -t mintty -s fish
> >
> > and invoke the new fish shell from
On 07/04/2014 23:35, Dave Kilroy wrote:
On 07/04/2014 13:02, Ronald Fischer wrote:
I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.
However, when doing a
chere -ifcm -t mintty -s fish
and invoke the new fish shell from the Windows Explorer context menu, I
On 07/04/2014 13:02, Ronald Fischer wrote:
I have installed fish 2.1.0. Works fine, when invoking a new fish shell
manually.
However, when doing a
chere -ifcm -t mintty -s fish
and invoke the new fish shell from the Windows Explorer context menu, I
get plenty of error messages, like this:
On Thu, Aug 01, 2013 at 01:38:07PM +0400, Andrey Repin wrote:
>Greetings, starlight.2013z3!
>>Some people like myself cannot abide subscribing to firehose mailing
>>lists and prefer to view discussion threads with a browser. It does
>>not mean contributors, direct or indirect, are any of value. E
Greetings, starlight.201...@binnacle.cx!
> Some people like myself cannot abide subscribing
> to firehose mailing lists and prefer to view
> discussion threads with a browser. It does not
> mean contributors, direct or indirect, are any
> of value. Even if I were a direct contributor
> monitori
Fixes the CTRL-C problem and the point
behind it all, running a critical build
script, work as well.
>
>stephan($0.02);
>
>-Original Message-
>From: cygwin-owner at cygwin dot com
>On Behalf Of starlight.2013z3 at binnacle dot cx
>Sent: Wednesday, July 31, 2013 10:26 AM
>
Well I uncovered a serious regression
and expressed a willingness to track
down the cause.
However your nasty reply and bad attitude
assures that I will defintiely not help
now.
At 01:21 PM 7/31/2013 -0400, Christopher Faylor wrote:
>You are right in assuming that newer DLLs should
>work with old
On Wed, Jul 31, 2013 at 12:24:32PM -0400, starlight.201...@binnacle.cx wrote:
>Have been running 1.7.16 for some time and living with the annoying
>CTRL-C hang bug.
>
>Tried swapping in cygwin1.dll cyglsa.dll and cyglsa64.dll from 1.7.22-1
>without (thankfully) updating the entire CYGWIN release.
>
On Nov 10 10:58, Corinna Vinschen wrote:
> On Nov 9 22:18, Leon Vanderploeg wrote:
> > Many thanks to Charles and Corinna for the help. I have modified the
> > code to use the POSIX functions. I still have one problem I cannot
> > seem to conquer.
> >
> > I need to be able to read and write t
On Nov 9 22:18, Leon Vanderploeg wrote:
> Many thanks to Charles and Corinna for the help. I have modified the
> code to use the POSIX functions. I still have one problem I cannot
> seem to conquer.
>
> I need to be able to read and write the (yes, I know it's evil)
> archive bit. Unless the
Many thanks to Charles and Corinna for the help. I have modified the code to
use the POSIX functions. I still have one problem I cannot seem to conquer.
I need to be able to read and write the (yes, I know it's evil) archive bit.
Unless there is a POSIX function (which I seriously doubt) fo
On Nov 3 17:56, Charles Wilson wrote:
> On 11/3/2011 4:48 PM, Leon Vanderploeg wrote:
> > With cygwin 1.7.5, cFileName with a special characters such as ñ (n
> > with tidle above it) fail be properly extracted from a
> > WIN32_FIND_DATA structure with findFirstFile (or findNextFile).
> >
> > To s
On 11/3/2011 4:48 PM, Leon Vanderploeg wrote:
> With cygwin 1.7.5, cFileName with a special characters such as ñ (n
> with tidle above it) fail be properly extracted from a
> WIN32_FIND_DATA structure with findFirstFile (or findNextFile).
>
> To set up a simple test scenario, I created a file in C
Hi,
On Wed, Nov 2, 2011 at 12:36 AM, Leon Vanderploeg wrote:
> Greetings,
>
> This issue is making my head flat from pounding it against the wall. It
> appears to be a bug in Cygwin 1.7, but I can't say with any certainty. I've
> been down too many dead end trails already...
>
> With cygwin 1
On Oct 25 07:06, Leon Vanderploeg wrote:
> I have been fighting a problem with a compiled C program and seem to have
> narrowed it down. When file names contain special characters such as the n
> with the tilde above it (ñ), stat() works fine on 32 bit machines, but fails
> on 64 bit machines (bot
On 02/01/2011 15:30, Jim Reisert AD1C wrote:
> I'm re-installing Cygwin from scratch, using the latest setup.exe on a
> Windows 7 64-bit system
>
> I had downloaded and installed gcc4, then discovered I had failed to
> download the corresponding g++ package. I ran "setup -M" and selected
> gcc4-g
snip<
I just discovered some additional information that may help get to the
bottom of this. Not sure what made me think of this, but I decided to try
an older version of rsync. If I run rsync 3.0.4-1 or 3.0.5-1, I
experience the problem. However, when I run 2.6.9-2, the only other
version of
On Jul 1 07:36, Lists wrote:
I tried it 6 times in a row, every time erasing the destination files.
Works fine for me.
Corinna
Perhaps you have hit upon the problem. I am just downloading and
running
setup-1.7.exe and it definetly has this problem. I tried to download
and
Setup-1.7.exe
On Jul 1 07:36, Lists wrote:
I tried it 6 times in a row, every time erasing the destination files.
Works fine for me.
Corinna
Perhaps you have hit upon the problem. I am just downloading and running
setup-1.7.exe and it definetly has this problem. I tried to download and
Setup-1.7.exe c
On Jul 1 07:36, Lists wrote:
>> I tried it 6 times in a row, every time erasing the destination files.
>> Works fine for me.
>>
>>
>> Corinna
>>
> Perhaps you have hit upon the problem. I am just downloading and running
> setup-1.7.exe and it definetly has this problem. I tried to download and
On Jun 26 23:42, Lists wrote:
On Jun 19 15:55, Lists wrote:
Works fine for me under the latest Cygwin 1.7.0-50 using your perl
script and your rsync options. I tend to agree to Larry's assumption
that some 3PP is interferring.
Sorry to just now be replying but I have been out of the country
On Jun 26 23:42, Lists wrote:
>> On Jun 19 15:55, Lists wrote:
>>>
>> Works fine for me under the latest Cygwin 1.7.0-50 using your perl
>> script and your rsync options. I tend to agree to Larry's assumption
>> that some 3PP is interferring.
>
> Sorry to just now be replying but I have been out
On Jun 19 15:55, Lists wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again. From
your
cygcheck output, it looks like things are not correct but this may be
just
a problem with an old cygcheck that doesn't know how to find the
implicit
mounts. If the issue is still the sam
On Jun 19 15:55, Lists wrote:
>
>> Can you upgrade to the latest Cygwin 1.7 package and try again. From your
>> cygcheck output, it looks like things are not correct but this may be just
>> a problem with an old cygcheck that doesn't know how to find the implicit
>> mounts. If the issue is still
Lists wrote:
Lists wrote:
Larry Hall wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again.
From your
cygcheck output, it looks like things are not correct but this may
be just
a problem with an old cygcheck that doesn't know how to find the
implicit
mounts. If the issue i
Lists wrote:
Larry Hall wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again. From
your
cygcheck output, it looks like things are not correct but this may be
just
a problem with an old cygcheck that doesn't know how to find the
implicit
mounts. If the issue is still the s
Lists wrote:
Larry Hall wrote:
Can you upgrade to the latest Cygwin 1.7 package and try again. From
your
cygcheck output, it looks like things are not correct but this may be
just
a problem with an old cygcheck that doesn't know how to find the implicit
mounts. If the issue is still the sa
Can you upgrade to the latest Cygwin 1.7 package and try again. From your
cygcheck output, it looks like things are not correct but this may be just
a problem with an old cygcheck that doesn't know how to find the implicit
mounts. If the issue is still the same, resending the output of the new
lists wrote:
See the attached cygcheck.out as per posting instructions. Note I have
also tried this on machines with much stronger hardware with the exact same
results. ALso note that the machine never runs out of memory so that doesn't
appear to be the problem either.
Not Found: awk
Not
On Jun 16 16:52, Jerry A wrote:
> Hi,
>
> I am a "local administrator" on an otherwise locked down corporate
> laptop that is running XP and currently, cygwin 1.7, the beta.
>
> I was running the released version of cygwin and having problems
> installing sshd and passwd. I found a thread from b
That certainly fixed it. Thanks.
-Greg
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Corinna Vinschen
> Sent: Tuesday, February 19, 2008 1:00 PM
> To: cygwin@cygwin.com
> Subject: Re: Possible Bug: Spurious SIGTERM from
On Feb 19 12:43, Greg Gibeling wrote:
> Program: cygrunsrv 1.20-1
> OS: Windows 2003 Server Enterprise Edition SP2
> Problem: The child process of cygrunsrv (openSSH/sshd in this case) receives
> a SIGTERM ~10-30 seconds after cygrunsrv is started.
Looks like a really dumb last-minute change on my
* Dave Korn (Fri, 10 Aug 2007 17:48:13 +0100)
> On 10 August 2007 17:23, Thorsten Kampe wrote:
> > * Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
> >> Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
> >>> Phil, please, you don't know what you're talking about and you don't
> >>> know what
Dave Korn wrote:
On 10 August 2007 17:23, Thorsten Kampe wrote:
* Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
[...]
As a matter of fact I stopped reading his article
after the line where he says d does not read ~/.d.conf because this
matched my own experience.
Bad practice. Stopping read
On 10 August 2007 17:23, Thorsten Kampe wrote:
> * Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
>> Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
>>> Phil, please, you don't know what you're talking about and you don't
>>> know what I and Ronald were talking about.
>>
>> If you re-read
* Phil Betts (Fri, 10 Aug 2007 17:05:18 +0100)
> Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
> > Phil, please, you don't know what you're talking about and you don't
> > know what I and Ronald were talking about.
>
> If you re-read what was posted, you'll find I was totally correct
>
* Dave Korn (Fri, 10 Aug 2007 16:49:31 +0100)
> On 10 August 2007 16:44, Thorsten Kampe wrote:
> > Fact is that d under Cygwin ignores ~/.d.conf while under Linux it works
> > as expected.
>
> >> Thorsten, he may or may not know what you're talking about, but your
> >> statement
> >>
>
Thorsten Kampe wrote on Friday, August 10, 2007 4:09 PM::
> Phil, please, you don't know what you're talking about and you don't
> know what I and Ronald were talking about.
I'm so sorry, but my telepathy module has a malfunction. Until it's
fixed, I can only respond to what is actually written
* Dave Korn (Fri, 10 Aug 2007 16:37:23 +0100)
> On 10 August 2007 16:22, Thorsten Kampe wrote:
>
>
> > The problem (/my/ problem and maybe Ronald's) is that d reads the home
> > directory from /etc/passwd and not from the environment variable
> > $HOME. In my setup these differ.
>
> Is that ev
On 10 August 2007 16:44, Thorsten Kampe wrote:
> Fact is that d under Cygwin ignores ~/.d.conf while under Linux it works
> as expected.
>> Thorsten, he may or may not know what you're talking about, but your
>> statement
>>
>> "d under Cygwin ignores ~/.d.conf "
>>
>> is demonstra
* Dave Korn (Fri, 10 Aug 2007 16:19:22 +0100)
> On 10 August 2007 16:09, Thorsten Kampe wrote:
> > * Phil Betts (Fri, 10 Aug 2007 15:04:11 +0100)
> >> Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
>
> >>> These resources don't contradict the info file but state the same.
> >>> Fact is
On 10 August 2007 16:22, Thorsten Kampe wrote:
> The problem (/my/ problem and maybe Ronald's) is that d reads the home
> directory from /etc/passwd and not from the environment variable
> $HOME. In my setup these differ.
Is that even valid? Hmmm. Posix does say:
http://www.opengroup.org/on
* Dave Korn (Fri, 10 Aug 2007 15:02:03 +0100)
> On 10 August 2007 14:21, Thorsten Kampe wrote:
> > * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
> >> Ronald Fischer wrote:
> >>> From
> >>>
> >>>info d
> >>>
> >>> we can see that /usr/bin/d is supposed to honour a configuration fil
On 10 August 2007 16:09, Thorsten Kampe wrote:
> * Phil Betts (Fri, 10 Aug 2007 15:04:11 +0100)
>> Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
>>> These resources don't contradict the info file but state the same.
>>> Fact is that d under Cygwin ignores ~/.d.conf while under Linux i
* Phil Betts (Fri, 10 Aug 2007 15:04:11 +0100)
> Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
> > * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
> >> Ronald Fischer wrote:
> >>> From
> >>>
> >>>info d
> >>>
> >>> we can see that /usr/bin/d is supposed to honour a confi
Thorsten Kampe wrote on Friday, August 10, 2007 2:21 PM::
> * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
>> Ronald Fischer wrote:
>>> From
>>>
>>>info d
>>>
>>> we can see that /usr/bin/d is supposed to honour a configuration
>>> file ~/.d.conf and that in this file, the boolean
On 10 August 2007 14:21, Thorsten Kampe wrote:
> * Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
>> Ronald Fischer wrote:
>>> From
>>>
>>>info d
>>>
>>> we can see that /usr/bin/d is supposed to honour a configuration file
>>> ~/.d.conf and that in this file, the boolean variable h
* Yaakov (Cygwin Ports) (Fri, 10 Aug 2007 07:09:11 -0500)
> Ronald Fischer wrote:
> > From
> >
> >info d
> >
> > we can see that /usr/bin/d is supposed to honour a configuration file
> > ~/.d.conf and that in this file, the boolean variable hidden-files-shown
> > corresponds to the --hidden-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ronald Fischer wrote:
> From
>
>info d
>
> we can see that /usr/bin/d is supposed to honour a configuration file
> ~/.d.conf and that in this file, the boolean variable hidden-files-shown
> corresponds to the --hidden-files flag in the d comma
(http://cygwin.com/acronyms/#PPIOSPE)
mwoehlke skrev:
> Bengt-Arne Fjellner wrote:
>> pgrep from procps-3.2.6-1 when asking for an exact match with
>> arguments seems to demand an extra space after the argument.
>> See the following sequence.
>>
>> No space after the f on the commandline $ emacs
Bengt-Arne Fjellner wrote:
pgrep from procps-3.2.6-1 when asking for an exact match with arguments seems to
demand an extra space after the argument.
See the following sequence.
No space after the f on the commandline
$ emacs f&
[1] 2072
without extra space
$ pgrep -x -f "emacs f"
with extra
Bengt-Arne Fjellner, le Tue 18 Jul 2006 00:00:46 +0200, a écrit :
> pgrep from procps-3.2.6-1 when asking for an exact match with arguments seems
> to
> demand an extra space after the argument.
> See the following sequence.
>
> No space after the f on the commandline
> $ emacs f&
> [1] 2072
>
>
>
> I would like to modify my program to set the required permissions.
> Is the mapping between Cygwin's uname()'s sysname and XP, NT, 98SE,
> 98, etc. available somewhere? Actually, if I could just tell if the
> underlying windows is XP, that would be sufficient I think.
The end of wincap.cc
Dave Bodenstab wrote:
On Thu Feb 2 22:55:08 2006 Corinna Vinschen <[EMAIL PROTECTED]> wrote:
Is this the way things are supposed to work on XP?
This is a constraint of the underlying OS, yes. The old implementation
of mmap used up to 1.5.18 didn't support PROT_EXEC at all, it was just
fake
On Thu Feb 2 22:55:08 2006 Corinna Vinschen <[EMAIL PROTECTED]> wrote:
> >
> > Is this the way things are supposed to work on XP?
>
> This is a constraint of the underlying OS, yes. The old implementation
> of mmap used up to 1.5.18 didn't support PROT_EXEC at all, it was just
> fake. Since 1
On Fri, 3 Feb 2006, Christopher Faylor wrote:
> ... One person even reported that a Cygwin bug caused OS "wrapping" and
> he found himself running FreeBSD...
Is that the "Blue Screen Of Life"?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_
On Feb 2 18:16, Dave Bodenstab wrote:
> I searched the mailing list archives and googled, but failed to find
> anything specific to XP regarding this...
>
> I am using the latest version (1.5.19-4) of Cygwin.
>
> I had previously ported a unix prog that used mmap to Cygwin. On win2k
> it works
On Fri, Feb 03, 2006 at 12:36:42AM -0600, Dave Bodenstab wrote:
>Is there a reference for what is returned for each windows release? On my
>only windows (I only have these for a couple of games and the digital cameras)
>systems I get:
>
> Win98SE sysname="CYGWIN_98-4.10"
> WinXP sysname="CYG
Thanks for the reply.
On Thu, 02 Feb 2006 21:47:55 -0700 Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Dave Bodenstab on 2/2/2006 5:16 PM:
> > mmap(0,1500,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE,,0)
> >
> > I've found that changing the permissions (chmod +x) on the file being
> > mma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Dave Bodenstab on 2/2/2006 5:16 PM:
> mmap(0,1500,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE,,0)
>
> I've found that changing the permissions (chmod +x) on the file being
> mmap'ed makes the problem go away.
>
> Is this the way things
Corinna Vinschen skrev:
> On Jun 21 09:14, Chris January wrote:
>> Bengt-Arne Fjellner wrote:
>>
>> > either /proc/prtitions has something wrong or i have.
>> > This is how it looks.
>> > $ cat /proc/partitions
>> > major minor #blocks name
>> >
>> > 8 0 19535040 sdaOK
>> > 8
On Jun 21 09:14, Chris January wrote:
> Bengt-Arne Fjellner wrote:
>
> > either /proc/prtitions has something wrong or i have.
> > This is how it looks.
> > $ cat /proc/partitions
> > major minor #blocks name
> >
> > 8 0 19535040 sdaOK
> > 816 78124095 sdbOK
> > 8
Bengt-Arne Fjellner wrote:
> either /proc/prtitions has something wrong or i have.
> This is how it looks.
> $ cat /proc/partitions
> major minor #blocks name
>
> 8 0 19535040 sdaOK
> 816 78124095 sdbOK
> 817 56196 sdb1 OK
> 818 61978770 sdb2 O
On Fri, 11 Mar 2005, Danny Smith wrote:
> I don't think your usage of .linkonce in your example is quite corect.
>
> In PECOFF, each linkonce symbol needs to have its own unique section. When
> you
> try to put more than one linkonce symbol into a section you get problems like
> those mentioned
Pavel Tsekov wrote:
> Hello,
>
> I found this one while playing with Cygwin's code which takes care of
> seamless loading of dll functions (autoload.cc). It seems that when a
> symbol in a section marked .linkonce is referenced, wrong relocation info
> is generated for that symbol.
>
> For example
but the below code in tvtime bootstrap works fine
--
test -x "$AUTOCONF" ||
AUTOCONF=`type -p autoconf2.50` ||
AUTOCONF=`type -p autoconf` ||
{
echo `basename $0`: cannot find GNU Autoconf 1>&2 &&
exi
Vijay Kiran Kamuju wrote:
> code in tvtime boot strap thats failing
> -
> test -x "$AUTOHEADER" ||
> AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`" &&
> AUTOHEADER=`type -p "$AUTOHEADER"` ||
> {
> echo `basen
oops in fedora its 1
code in tvtime boot strap thats failing
-
test -x "$AUTOHEADER" ||
AUTOHEADER="autoheader`echo "$AUTOCONF" | sed 's/.*autoconf//'`" &&
AUTOHEADER=`type -p "$AUTOHEADER"` ||
{
echo `basename $0`: GNU Autoco
Álvaro Suárez Sarmiento wrote:
> I would be grateful if you indicate me how to correct the errors, or indicate me
> if this is a bug in "gcc".
Build problems are rarely bugs in the compiler. The makefile or build
environment (locally installed libraries, headers, include directories,
etc.) are
$ uname -a
CYGWIN_NT-5.0 P450 1.5.10s(0.114/4/2) 20040420 11:21:06 i686 unknown unknown
Cygwin
This is: Win2K advanced server, SP4+all updates, cygwin w most (but no all)
recent updates and the 2004-04-20 snapshot dll.
$ cat stat.c
#include
#include
#include
int main()
{
char filename[10
Nicholas Wourms wrote:
[SNIP]
#define strong_alias(name, aliasname) \
extern __typeof__(name) aliasname __attribute__((__alias__(#name))); \
__asm__(".def \"_" #aliasname "\"; .scl 2; .type 32; .endef\n");
^^ ^^
Sorry,
Ack, I pasted an older version of the macro, w
Danny Smith wrote:
Nicholas wrote:
One problem is that you (or gcc) need to tell ld that 'foo' is function, not
data.
I'll be the first to admit that I'm almost totally w/o a clue when it
comes to assembly. I'm afraid the gas manual is not very helpful in my
effort to alleviate this :-(.
Add
Nicholas wrote:
> Hi All,
>
> Gerrit and I were discussing this off-list, but I thought it appropriate
> that I move it to the main list since he has confirmed the problem.
>
> Here's the problem, programs are segfaulting when the are linked to a
> symbol which was aliased using __attribute__((a
Rolf Campbell wrote:
C: is not mounted in text mode. /c is mounted in text mode. C: isn't
mounted at all.
I see your point. However, prior to 1.5 the mount table worked (i.e.,
determined the file mode) even if the path started with "C:", as far as
I understand.
If you set CYGWIN=textmode then that
Vladimir Vysotsky wrote:
Hi,
I'm using the following sequence of actions to reproduce this problem:
C:\test>bash
bash-2.05b$ echo "Test" >/c/test/test1.txt
bash-2.05b$ echo "Test" >c:/test/test2.txt
bash-2.05b$ ls -l
total 2
-rw-r--r--1 vvysotsk mkpasswd6 Oct 10 19:49
Jeff wrote:
Vlad wrote:
In other words, text mode is ignored if Windows-style path is
specified.
I noticed this same behavior and posted on it a bit earlier this month.
Jeff, I've noticed your email after I've posted mine :) I believe it's
the same problem.
$ command -option `cygpath c:\whereever\
Vlad wrote:
>In other words, text mode is ignored if Windows-style path is
>specified.
>
>I'm concerned about this behavior because it breaks some 3rd party
>tools that I'm using. In particular, a C compiler chokes on
>multiline macros. As a result, I have to juggle between 1.5 (for normal
>usage)
Hello David,
I tried your patch below with emacs-21.3 and emacs cvs head and it
works very fine with gcc 3.2 and the latest cygwin release. So
hopefully the patch is soon included into cvs. Thanks for your fast
reply.
Harald
David Ponce <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.
"Peter Milliken" <[EMAIL PROTECTED]> writes:
> I have downloaded the source of 21.3 and built it on a PC running Win2000
> and using the Cygwin distribution and following the INSTALL instructions
Thanks for taking the time to look at this - I really appreciate that.
BTW: If it's reproducible, tell me the steps and I'll look too. Also, if
it's reproducible, try building with -DDEBUG.
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygw
> -Original Message-
> From: Pavel Tsekov [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, March 23, 2002 11:03 AM
> strcpy (dp, dots);
> delete[] dots;
> key = String (dp);
>
> LOOK HERE - This is not right - we should delete at the base
> of the block, not somewhere in the middle
/bin/sh on Cygwin doesn't understand the ~ character. It's a rather
limited shell.
try this:
:set shell=/bin/bash
Luke
On Mon, 4 Mar 2002, Pavel Tsekov wrote:
> Hey, there! :)
>
> I have noticed the following behaviour of VIM and thought it is worth
> reporting it to the list. Trying to exec
--- Julian Hall <[EMAIL PROTECTED]> wrote: >
> Hi; I don't know whether this has been mentioned before, but I just had
> a bug report for NASM, which I am one of the maintainers of, relating to
> linking code assembled by NASM with the cygwin or mingw linkers.
>
> I've done a little investigati
95 matches
Mail list logo
