I can't see a command like
cygcheck -p ssh-keygen
as noticeably more cumbersome than comparable commands of other
distributions
Lee via Cygwin schrieb am Mo., 20. Nov. 2023, 23:42:
> On Mon, Nov 20, 2023 at 11:54 AM Matthias wrote:
> >
> > Dear all,
> >
> > I've installed cygwin 3.4.9-1
Am 20.11.2023 um 17:54 schrieb Matthias--- via Cygwin:
Unfortunately I can't find ssh-keygen in the installable packages.
That's quite strange, given ssh-keygen is clearly right there in that
openssh package:
$ cygcheck -f /usr/bin/ssh-keygen.exe
openssh-9.5p1-1
--
Problem reports:
Am 09.08.2023 um 21:17 schrieb Wendy Lin via Cygwin:
How can I compile
https://github.com/microsoft/Windows-driver-samples/tree/main/filesys/cdfs
with Cygwin gcc?
You should not be trying to do that.
That's deeply system-specific Windows code. It has nothing to with
POSIX, Cygwin or
Am 18.06.2023 um 21:35 schrieb tlake--- via Cygwin:
I can use an emulated LPT port to a shared network printer from Cygwin but
I'd like to print to a local LPT port also.
The local printer has no IP address. Is it possible to print to a physical
LPT port?>
If I do this:
ls >
Am 07.02.2023 um 07:59 schrieb Yeo Kai Wei via Cygwin:
I think I found the issue, I believe it's due to MinGW's build of gcc (I
could be wrong).
I downloaded "gcc -core" and it worked.
You keep talking of "downloading" and "unpacking" things. That
indicates a continuing misunderstanding
Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin:
The build system, finding it is running on Windows, will pass paths with
backward slashes to the compiler.
And that's wrong. Cygwin is not, for practical intents and purposes,
Windows. It just runs on top of it.
Yes, backslashed
Am 18.05.2022 um 03:53 schrieb David Christensen:
> I am working on a Perl module that runs on various Unix-like platforms.
> When I 'make test' on similar computers:
>
> FreeBSD 12.3-RELEASE 28 wallclock secs
> Debian GNU/Linux 11.3 31 wallclock secs
> macOS 11.6.2
Am 29.04.2022 um 18:40 schrieb David Rogers via Cygwin:
I successfully installed:
alternatives1.3.30c-10 OK
According to the alternatives package file list I should have the following executables installed: alternatives.exe and
Am 15.02.2022 um 02:36 schrieb Hans-Bernhard Bröker:
Am 13.02.2022 um 19:25 schrieb Achim Gratz:
There is no OS specific configuration for Cygwin explicitly, instead
there is one for newlib that actually gets used.
This piqued my curiosity, so I had a look at how libstdc++ is built. I
Am 13.02.2022 um 19:25 schrieb Achim Gratz:
Gans, Markus writes:
This seems to be an internal Cygwin error:
https://www.reddit.com/r/cpp_questions/comments/sp52gq/xdigit_does_not_work_with_stdwstring_in_a_cygwin/
[…]
Question: Why does Cygwin not detect the letters a, b, c, d, e, and
f
Am 14.12.2021 um 18:45 schrieb robhic...@gmx.com:
Hi Cygwin,
I'm compiling a non Cygwin code using ./config, make, make install.
How exactly are you using "./config"? Is it a normal GNU autoconf
./configure script? If so, you should probably have made that point to
the mingw
Am 27.09.2021 um 13:27 schrieb Anthony Webber:
Anyway, I am trying to set up my gcc toolchains in Cygwin, by which I
mean that I'm trying to set up the environment so that the right
programs are called at the right time by build systems like cmake and
waf, or if I want to build in a more
Am 19.09.2021 um 00:32 schrieb Ken Brown via Cygwin:
Finally, I'd like to mention that it's extremely common for
autotools-based packages to have an autogen script like Cygwin's
(sometimes called bootstrap or bootstrap.sh). There's nothing
surprising about this.
It's unsurprising to have
Am 28.08.2021 um 18:23 schrieb Dan Harkless:
Looks like it's because in findutils 4.8.0-1, the bigram.exe program is
no longer provided, but the /usr/bin/updatedb script (still) depends on
it being there:
[...]
+ for binary in $find $frcode $bigram $code
+ checkbinary
Am 13.05.2021 um 10:57 schrieb Thomas Wolff:
The crash vanishes after removing a few lines from a conditional (if
block) where the condition is false.
A conditions that's always false, or one that's false during the
execution of a particular test case?
This smells like wrong calculation of
Am 27.03.2021 um 13:58 schrieb Brad Bell:
It appeard that I need to add an non-standard location to a path so that
the linker can find these files ?
Read those error messages again. It's failing to find things _in_ any
of those files, which means it did in fact find all files it was looking
Am 24.03.2021 um 21:58 schrieb Ken Brown:
On 3/24/2021 2:55 PM, Hans-Bernhard Bröker wrote:
Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches:
> On Mar 22 22:54, Hans-Bernhard Bröker wrote:
>> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin:
It's what WSL Debia
Am 23.03.2021 um 10:30 schrieb Corinna Vinschen via Cygwin-patches:
> On Mar 22 22:54, Hans-Bernhard Bröker wrote:
>> Am 22.03.2021 um 16:22 schrieb Johannes Schindelin:
>>> One of those under-documented reparse point types is the WSL symbolic
>>> link, which yo
Am 22.03.2021 um 16:22 schrieb Johannes Schindelin:
On Mon, 15 Mar 2021, Hans-Bernhard Bröker wrote:
Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches:
That argument might hold more sway if Windows itself didn't quite so
completely hide that information from users, too
Am 15.03.2021 um 04:19 schrieb Johannes Schindelin via Cygwin-patches:
Hi Joe,
On Sat, 13 Mar 2021, Joe Lowe wrote:
I agree on the usefulness to the user of showing appexec target executable as
symlink target. But I am uncertain about the effect on code.
Maybe. But I am concerned about the
Am 22.02.2021 um 21:30 schrieb Brian Inglis:
I've often wondered if the heavy activity is due to Windows' defaults to
writing files with F+RX perms which triggers executable virus scans?
That could only be the case if Windows actually had an 'x' permission bit.
--
Problem reports:
Am 29.01.2021 um 00:36 schrieb Rafał Jopek via Cygwin:
Hi,
What package should be installed ?
None. This is quite certainly a packaging mistake on a package you
already have installed.
In short: that file should be in cygwin-devel, but it isn't.
--
Problem reports:
Am 17.01.2021 um 19:23 schrieb matthew patton via Cygwin:
can we fix setup.exe to read STDIN with '-P', like so?
To fix something, it has to be broken first. I don't see that being the
case here.
echo 'pkg1,pkg2,pkg3' | setup.exe -P -
I don't see that in any way easier or more helpful
Am 16.01.2021 um 05:40 schrieb Marco Atzeri via Cygwin:
It seems the remote machine is expecting to run a X interface
by default.
Or could it be that the local machine has ssh X11 forwarding turned on
(for this remote machine)? Turning it off explicitly (-x flag) would
turn it off, so if
Am 06.01.2021 um 19:17 schrieb Kamran via Cygwin:
Hi all
"ls" (version 8.26) sorts wrongly if given large number of files via
"find" or "xargs"
Actually ls is working just fine here. You just misunderstand how
"find" works in this case.
To see what actually happens, you should run
Am 05.01.2021 um 22:04 schrieb Andrey Repin:
It's a Windows program - it can do whatever you program it to do!
On Windows the device is NUL, the root is the drive root C:\,
%SystemDrive%\ to be precise.
Well, since we're being precise: no.
%SystemDrive%\ is the root of the drive the system
Am 20.12.2020 um 00:34 schrieb Jason McGee via Cygwin:
I confirmed there is not a problem with my code by comparing Cygwin against
Gawk for Windows.
Your presentation of the problem is quite unclear, but the root cause is
almost certainly not in the code, but in the data.
You're bound to
Am 15.11.2020 um 04:59 schrieb Juan carlos Rebate via Cygwin:
Hello, I am trying to compile certain programs in windows 10 and I
have a curious problem, I use mingw64-x86_64-w64-mingw, when I add
related packages if it is able to locate them but if I install
packages that are not related it is
Am 04.11.2020 um 10:36 schrieb Ponnusamy, Sathiyamoorthy (Extranet) via
Cygwin:
Hi Team,
I am facing Cygwin issue while downloading the code.
I don't think you do. Cygwin has very little, if anything, to do with
this issue.
I need this Cygwin tool urgently for the current project
Am 16.09.2020 um 13:12 schrieb Thomas Wolff:
Am 16.09.2020 um 13:04 schrieb marco atzeri via Cygwin:
On Wed, Sep 16, 2020 at 10:53 AM Kristian Ivarsson via Cygwin
Does anyone know the rational with this behaviour and what can be
done to
get hold of the (real) Windows TMP/TEMP
Am 07.09.2020 um 01:00 schrieb Ulli Horlacher:
cygstart /setup-x86_64.exe --quiet-mode
That approach is essentially guaranteed to fail you in frustrating ways,
for two reasons:
1) (Minor) You do not want to have setup itself, much less its work and
data directory, inside the cygwin
Am 28.08.2020 um 00:51 schrieb Juan carlos Rebate via Cygwin:
good evening, I have a strange problem, I try to compile code that
uses gtk3 and sdl2 in addition to curl,
Would you mind revealing what code that is?
the problem is that when I
invoke the gcc compiler it tells me that
Am 24.05.2020 um 17:30 schrieb Juan carlos Rebate via Cygwin:
[Can you _please_ cut down on the TOFU? Thanks ]
Hi Caba, I know qemu-system-i386 because the official binary is that
\
size.As for the command used I use this:x86_64-w64-mingw32- this way it
Am 20.03.2020 um 00:18 schrieb Brian Inglis:
On 2020-03-18 23:25, Marco Atzeri via Cygwin wrote:
It seems something is adding 5M or more to the normal
size of the programs
See attached for summary details by arch, but main points for both are, on
x86_64:
[...]
Could this be due to the
Passing a pointer to a local variable to WriteConsoleA is
not actually needed if we're not going to do anything with
what WriteConsoleA would put in there.
For the wpbuf class the pointer argument was made optional,
so it can be just left out; other call places now pass a
NULL pointer instead.
Replace direct access to a pair of co-dependent variables
by calls to methods of a class that encapsulates their relation.
Also replace C #define by C++ class constant.
---
winsup/cygwin/fhandler_console.cc | 141 --
1 file changed, 76 insertions(+), 65 deletions(-)
Second shot at wpbuf class-ification. Also no longer
request data from WriteConsoleA that is not used for anything.
Hans-Bernhard Broeker (2):
Collect handling of wpixput and wpbuf into a helper class.
Do not bother passing optional argument to WriteConsoleA.
Second shot at wpbuf class-ification. Also no longer
request data from WriteConsoleA that is not used for anything.
Hans-Bernhard Broeker (2):
Collect handling of wpixput and wpbuf into a helper class.
Do not bother passing optional argument to WriteConsoleA.
Am 04.03.2020 um 04:52 schrieb L A Walsh:
On 2020/03/03 15:45, Hans-Bernhard Bröker wrote:
Am 04.03.2020 um 00:25 schrieb L A Walsh:
On 2020/02/28 04:38, Fergus Daly wrote:
I am almost certain that the command
$ rename "anything" "AnyThing" *.ext
would alter the string fr
Am 04.03.2020 um 00:25 schrieb L A Walsh:
On 2020/02/28 04:38, Fergus Daly wrote:
I am almost certain that the command
$ rename "anything" "AnyThing" *.ext
would alter the string from lc to uc as shown, anywhere it occurred in
any filename in *.ext in the current directory.
isn't that they
Am 03.03.2020 um 01:35 schrieb Takashi Yano:
The second argument DWORD *wn of sendOut() is not used
outside sendOut(), so it can be covered up like:
inline void sendOut (HANDLE )
{
DWORD wn;
WriteConsoleA (handle, buf, ixput, , 0);
}
I doubt that will improve much, if anything. There
Replace direct access to a pair of co-dependent variables
by calls to methods of a class that encapsulates their relation.
Also replace C #define by C++ class constant.
---
winsup/cygwin/fhandler_console.cc | 135 --
1 file changed, 70 insertions(+), 65 deletions(-)
Replace a relatively C-styled co-dependent pair of variables, a #define,
and an inline function by a helper class containing their relation,
because that is more in the C++ style.
Hans-Bernhard Broeker (1):
Collect handling of wpixput and wpbuf into a helper class.
To whom it may concern,
I hereby grant anyone the rights to any use code I send here under the
standard 2-clause BSD license statement as found, among other places, in
winsup/cygwin/CONTRIBUTORS.
Hans-Bernhard Bröker
Am 01.03.2020 um 07:33 schrieb Takashi Yano:
However, from the view point of performance, just inline
static function is better.
I don't see how that could be the case. Inline methods of a static C++
object should not suffer any perfomance penalty compared to inline
functions operating on
One more important note: the current implementation has a potential
buffer overrun issue, because it writes first, and only then checks
whether that may have overrun the buffer. And the check itself is off
by one, too:
wpbuf[wpixput++] = x; \
if (wpixput > WPBUF_LEN) \
wpixput--;
Am 28.02.2020 um 14:31 schrieb Corinna Vinschen:
[CC Hans]
Thanks. I wasn't subscribed to -patches so far. Will change that.
Hans,
as for making a patch for this issue, may I leave it to you
because you are already working on it?
My patch was meant only as a minimally-invasive stop-gap
winsup/cygwin/fhandler_console.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 4ab9bcab8..353abd197 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
Am 21.02.2020 um 18:22 schrieb David Rothenberger:
With cygwin 3.1.4, I get an "exception c005" when I perform the
following actions:
1. Use the Windows run box to start a cmd shell
2. From there, run "bash". (I'm sure it is the Cygwin bash.)
How did you make sure of that? The output of
[Ooops, sent this to Takashi instead of the list, originally.]
Am 29.01.2020 um 14:46 schrieb Takashi Yano:
On Wed, 29 Jan 2020 13:19:11 +0100
Marco Atzeri wrote:
As Octave uses gnulib, it is possible that the changes in MS are causing
a different subset of gnulib to be used than before, may
Am 29.01.2020 um 01:02 schrieb Hans-Bernhard Bröker:
So re-run it in gdb, via libtool (run-octave -g ...). Still crashes,
but I didn't manage to get around the SIGSEGV handler in octave. It
always caught the SEGV before gdb managed to get there.
So my finding, so far, would
Am 25.01.2020 um 17:55 schrieb Marco Atzeri:
libinterp/corefcn/file-io.cc-tst
...fatal: caught signal Segmentation fault
-- stopping myself...
/bin/sh: line 1: 3771 Segmentation fault (core dumped) /bin/sh
../run-octave --norc --silent --no-history -p
Am 27.01.2020 um 13:58 schrieb Ken Brown:
On 1/26/2020 10:25 PM, Hans-Bernhard Bröker wrote:
Am 25.01.2020 um 15:23 schrieb Rodrigo Medina:
Hi,
Both installations of grace-5.1.24 and grace-5.1.245 are broken.
/usr/bin/xmgrace.exe runs but gives the message:
--> Broken or incompl
Am 25.01.2020 um 15:23 schrieb Rodrigo Medina:
Hi,
Both installations of grace-5.1.24 and grace-5.1.245 are broken.
/usr/bin/xmgrace.exe runs but gives the message:
--> Broken or incomplete installation - read the FAQ!
and then quits.
After reading the FAQ and comparing with a direct build
Am 24.01.2020 um 00:31 schrieb Jim Zheng:
I seem to be running into an issue with my terminal not being
recognized after updating to the latest terminfo (6.1-1.20190727).
Setting TERM to anything other than 'xterm' results in loss of
terminal control where I am unable to use
Am 04.11.2019 um 23:06 schrieb Caines, Brian:
> Hi, on the current website version it is listed as 3.0.7. However, when I
> install it and right click on the terminal window -> Options -> About, it
> says 3.0.6.
You're looking in the wrong location.
What you're looking at is the version of the
Am 04.11.2019 um 02:06 schrieb Lawrence Clooney:
> Error Message:
> checking whether to use NLS... no
> checking for initscr in -lncurses... yes
> checking ncurses.h usability... yes
> checking ncurses.h presence... yes
> checking for ncurses.h... yes
> checking for Berkeley DB db.h version >= 4.1
Am 27.10.2019 um 04:33 schrieb William John:
> Dear Cygwin,
>
> I recently installed openmpi and libopenmpi-devel on my windows machine.
> However, I cannot call mpicc on my windows cmd, rather I get "'mpicc' is
> not recognized as an internal or external command, operable program or
> batch
Am 11.09.2019 um 02:03 schrieb Blair, Charles E III:
> I have just installed cygwin (64 bit) and gcc. The "hello world" program
> works, but
>
> #include
> int main(){printf( "%c\n" , 'X' );return 0;}
>
> leads to
>
> Unable to initialize device PRN
> Unable to initialize device PRN
I
Am 21.08.2019 um 21:39 schrieb L A Walsh:
>> apropos cut|grep -iP 'copy|paste'
> and found (among others)
> wxcopy (1x) - copy stdin or file into cutbuffer
> wxpaste (1x) - output a cutbuffer to stdout
> xcb (1x) - X Cut Buffers - Pigeon holes for your cut and
> paste
Am 16.08.2019 um 15:28 schrieb David Karr:
> On Fri, Aug 16, 2019 at 3:50 AM Andrey Repin wrote:
>> Do you have %HOME% variable set in your user environment?
>> Do you have %HOMEDRIVE%/%HOMEPATH% variables defined to something
>> unsettling?
> I checked "Environment Variables" in control panel,
Am 10.08.2019 um 10:01 schrieb Houder:
> Remarkably https://sourceforge.net/projects/cscope/ (news)
> reports v15.8b as the last release ...
>
> ... though v15.9 is mentioned at a different tab (git).
>
> But really, what changed? (why NO annoucement?)
That one's on me. I'm the maintainer of
Hello one and all,
As of commit b66dddb56d14a4032969fe8bb92d64baa6e0362e,
winsup/cygwin/uname.cc no longer compiles with the current GCC version
installed with cygwin itself. The newly added __attribute__ is unknown
to GCC 7, and thus triggers a -Werror for unused/unknown attributes:
$ LANG=C
Am 18.07.2019 um 10:03 schrieb Fergus Daly:
> I have
> none / cygdrive binary 0 0
> as the only line in the file /etc/fstab to allow for example
> $ ls /h/config.sys
> instead of the long-hand
> $ ls /cygdrive/h/config.sys
And that's precisely your problem. You've now overlaid two mount points
Am 30.06.2019 um 07:37 schrieb Federico Kircheis:
> My problem is that cyport tries to invoke tar with an absolute file, and
> of course C:\Windows\system32\tar.exe does not understand a path that
> begins with `/cygdrive/c`.
No. Your problem is that you're trying to use cygport from the wrong
Am 21.06.2019 um 17:19 schrieb reiter.christ...@gmail.com:
> Hey everyone,
>
> I have to following problem (using cmd.exe):
>
> C:\cygwin64\home\xy>C:\cygwin64\bin\echo.exe -DFOO=\"BAR\" -DBAR=\"FOO\"
> -DFOO=\BAR" -DBAR="FOO"
>
> I would have expected:
>
> -DFOO="BAR" -DBAR="FOO"
Expecting
Am 06.06.2019 um 21:18 schrieb Hans-Bernhard Bröker:
> Still that would constitut, if not a flat-out bug, at least severe
> bit-rot in the upstream package, because if it doesn't work with
> Cygwin's automake version 1.15, it most likely doesn't with reasonably
> current versions
Am 06.06.2019 um 10:03 schrieb Soegtrop, Michael:
> From a tarball. As far as I can tell I am exactly reproducing the
> original package that is available as binary on Cygwin repos with
> exactly the same sources, patches and cygport file.
... but possibly way different versions of the autotools
Am 05.06.2019 um 11:53 schrieb Soegtrop, Michael:
The reason is that aclocal is missing a "-I m4" option to include the
local m4 subfolder. I wonder what I need to do in the cygport file to
add this. Or should this be added in gnome2_autogen.sh.
If that had to be done, that would constitute a
Am 20.05.2019 um 21:12 schrieb Jose Isaias Cabrera:
> There is no configure script on the source directory,
And that should have been a warning to you.
This is the most portability-ignorant open source package I've seen in a
long time, and by a very wide margin. They don't even _try_ to
Am 12.05.2019 um 20:22 schrieb Agner Fog:
> I have noticed that the gcc and clang compilers have defined the
> preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64
> when compiling a windows executable.
>
> Why is this?
Because it's correct that way. Cygwin runs on Windows, but
Am 25.04.2019 um 18:11 schrieb Peter Palaparthy:
> Cygwin bash script is removing equals sign from command call.
On what basis did you conclude it was bash doing that, and not, say, make?
> *Here is the relevant command in my makefile.*
> *$(elabcmd) = $(XELAB_DEFAULT) \-generic VERSION=10*
I
Am 25.04.2019 um 17:48 schrieb Eric Blake:
> On 4/25/19 10:28 AM, Brian Inglis wrote:
>> Would it be allowed and valid to #define MSG_EOR 0 to simplify lack of
>> support?
>
> No, because that implies that EVERY send() call is requesting MSG_EOR
> and that it never fails.
And maybe more
Am 24.04.2019 um 19:54 schrieb Eliot Moss:
> On 4/24/2019 12:43 PM, Corinna Vinschen wrote:
>> Since MSG_EOR isn't implemented in the underlying transport layer,
>> there's no way to implement it in userspace. That's why it's not
>> defined in Cygwin's headers. If you have an idea how to
[A side note, first: this is a traditional mailing list, i.e. the policy
is snipping and bottom-replying...]
Am 19.04.2019 um 01:41 schrieb Carlo B.:
> I have no idea how you can run it without errors, please note that
> i586-pc-msdosdjgpp-gcc works fine until it does not link.
Please note
Am 18.04.2019 um 16:11 schrieb Carlo B.:
> I would like to signal that the DJGPP cross compiler, included into
> the available packages, crashes as soon as you try to compile
> something with it.
Doesn't, here. It just works.
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Am 26.11.2018 um 21:32 schrieb Gilbert St. Firmin:
> Could the native Windows version of 7-zip be used on both old and new
> computers?
Possibly. If that can be taught to copy all the attributes used by
Cygwin, without running into the usual problems we see whenever Windows
tools are used to
Am 25.11.2018 um 15:38 schrieb Lester Ingber:
> I'd like to simply transfer my cygwin64/ directory from my old Thinkpad
> to my new Thinkpad, both running Win 10 x64 Pro. E.g., I would put my
> old c:/cygwin64/ onto a flash SSD USB drive e:/ .
> cd c:/
> tar cfp - cygwin64 > e:/cygwin64.tar &
>
Am 24.10.2018 um 22:49 schrieb Andrey Repin:
> Greetings, Stefan Baur!
>
>> if you can either get hold of the current mailing list's subscriber
>> list, to auto-subscribe everyone to a new list, or you are able change
>> the current mailinglist's address to, say, cygwin...@cygwin.com, you
>>
Am 14.10.2018 um 23:20 schrieb hacker...@protonmail.com:
> Hello,
>
> I have a program that uses X11/Motif and runs fine, within Cygwin/X on the PC
> it was compiled on.
>
> What is the *minimum* required set of Cygwin libs and any other files I need
> to distribute along with, it to end-users
Am 25.09.2018 um 17:16 schrieb Fergus:
Unintentionally I have confounded the discussion. The directory named
"consoleX" is my home-grown Cygwin root directory.
(Others' preferred locationname might be "cygwin" or "mycygwin" or
whatever.)
That does not explain anything, actually. Cygwin's own
Am 05.09.2018 um 07:55 schrieb John Selbie:
With this: g++ foo.cpp -c -std=c++11
It compiles fine everywhere else, except CygWin. Output on Cygwin:
I'm afraid that may mean everywhere else is wrong.
Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the command
line line works.
Am 02.09.2018 um 03:22 schrieb Darren Whobrey:
The tweak required to get OpenSC to work with the standard Cygwin
utils, like ssh-agent, is to comment out a line in the configure.ac
script that previously was causing it to force a WND build, which
resulted in struct packing of 1 – and that
Am 25.08.2018 um 02:13 schrieb Steven Penny:
On Fri, 24 Aug 2018 10:11:42, JonY wrote:
$ wc -c /lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a
22446354 /lib/gcc/x86_64-w64-mingw32/7.3.0/libstdc++.a
$ wc -c mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/libstdc++.a
5597192
Am 25.07.2018 um 20:50 schrieb Brian Inglis:
If you use a Cygwin shell you can see /usr/{bin,lib}/, etc.; if you use a
Windows shell you can not.
That's got nothing to do with the shell. It only depends on whether the
program that does the "seeing" is a cygwin-based one or not. From a
Am 25.07.2018 um 12:39 schrieb John Delaney:
As I have done many times before, I attempted to update my 32-bit
Cygwin installation around midnight 7/24-25/ 2018.
This time the process failed at about 99% complete. " /etc/postinstall/
texlive-collection.basic.sh" failed to complete repeatedly
Am 13.06.2018 um 01:30 schrieb Alejandro Benitez:
It's somehow clear I thankfully won't need to upgrade to cygwin64 until later,
While you don't need to do it, you'll have to re-install Cygwin anyway,
and frankly, installing 32-bit Cygwin from scratch, on a 64-bit Windows
machine, just
Am 08.06.2018 um 17:16 schrieb Denis Nikiforov:
/usr/include/boost/process/detail/posix/is_running.hpp:18:1: error:
non-constant condition for static assertion
static_assert(!WIFEXITED(still_active), "Internal Error");
^
__wait_status_to_int must be a macros but it's redefined
Am 05.06.2018 um 17:56 schrieb Ivan Shynkarenka:
Hello,
I found an issue with Cygwin GCC 7.3.0 when building with -std=gnu++17
flag.
Using Cygwin 32-bit or 64-bit? I have to ask because I could not
reproduce your problem here, on the 64-bit version.
Build: g++ -std=gnu++17 test.cpp
Am 15.05.2018 um 19:17 schrieb Michael Enright:
The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using
-gdwarf2 with assembly code manually or through gcc is successful in
producing a Cygwin64 executable that Cygwin64 GDB can work with. This
combination of circumstances led me to
Am 13.05.2018 um 18:01 schrieb waterlan:
The C flag that triggers this option is -Wp,-D_FORTIFY_SOURCE=2.
That does look rather weird. Why would one write that instead of just
-D_FORTIFY_SOURCE=2 ?
Anyway, the test can be simplified quite a lot to:
hbbro@NB4 ~/tmp
$ cat twchar.c
#include
Am 08.05.2018 um 13:22 schrieb David Spencer:
Morning,
I am trying to get CYGWIN Version 2.8, this is the only version approved for our system at present,
Providing that is, to a great extent, actually the job of whoever
approves versions of Cygwin for you.
That's because the version
Am 08.04.2018 um 05:11 schrieb Duncan Roe:
I tried in 64-bit with the same result as Eliot: works fine w/out
feenableexcept, no o/p with feenableexcept.
Just in case this may have been overlooked: please note that "no output"
actually means the program crashed because of an uncaught SIGFPE,
Am 05.04.2018 um 11:19 schrieb Peter Bauer:
i was bitten by the length limit of the PATH variable of 4095 characters
(see [1]) and could not find a way around it. This means i have a lot of
software packages in different directories and each of them adds itself
to the PATH so one can run the
Am 23.01.2018 um 02:49 schrieb Brian Inglis:
I was surprised when I looked at the log (attached, with lots of man directory > indexing stripped), that mandb -p decide to scan my C drive and
perform the
It probably wasn't actually scanning "the C drive" as such, but rather
the neighboring
Am 13.12.2017 um 14:28 schrieb Ken Brown:
When setup is preparing to download files and it finds a corrupt copy in
the local cache, it issues a fatal error message telling the user to
remove the corrupt file and retry. Steven said that setup should
silently delete the corrupt file, while I
Am 20.10.2017 um 14:50 schrieb Peter Quiring:
The mingw versions have x86_64-w64-mingw32- or i686-w64-mingw32- added
to their exe names. Currently I just use these directly but I want to
use cmake.
You can just tell cmake to use them:
cmake -D CMAKE_C_COMPILER=x86_64-w64-mingw32-gcc
Am 26.09.2017 um 07:32 schrieb Marco Atzeri:
"The header shall define the fd_set type as a structure."
so if they are using it, they should have a proper include
The complete story is a bit more complicated than that, though.
The curl maintainers almost fixed this at their end, but then
Am 25.09.2017 um 20:44 schrieb Steven Penny:
perhap you are using old versions
Not exactly. I'm using the current versions: 2.25.0.1, 5.4.0
respectively --- you're using not old enough, a.k.a. still "Test"ing
versions ;-)
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Am 25.09.2017 um 03:53 schrieb Steven Penny:
On Sun, 24 Sep 2017 00:48:20, JonY wrote:
I don't really work with cmake, but what it looks like, but it probably
makes gcc look in the mingw include dir first and then gcc's, breaking
gcc's headers.
Correct thus far. -isystem is really not a
1 - 100 of 160 matches
Mail list logo
