Guys, I already applied a patch.
Thanks,
Corinna
On Mar 5 15:51, Glenn Strauss via Cygwin wrote:
> On Wed, Mar 05, 2025 at 08:27:53PM +, Lavrentiev, Anton (NIH/NLM/NCBI)
> [C] via Cygwin wrote:
> > > We could change this to a macro instead:
> > >
> > > -static inline void setproctitle_init
On Wed, Mar 05, 2025 at 08:27:53PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
via Cygwin wrote:
> > We could change this to a macro instead:
> >
> > -static inline void setproctitle_init (int, char *[], char *[]) {}
> > +#define setproctitle_init(c, a, e)
>
> Changing to the empty marco removes
> We could change this to a macro instead:
>
> -static inline void setproctitle_init (int, char *[], char *[]) {}
> +#define setproctitle_init(c, a, e)
Changing to the empty marco removes the side effects in the arguments (such as
len++, for example),
which may silently break existing code -- so
On Mar 5 20:10, Dimitry Andric via Cygwin wrote:
> Maybe it's because -Wsystem-headers is not enabled? I'm unsure what
> gcc's default behavior is with -Wall, but if you add an explicit
> -Wsystem-headers you might still get that warning.
Thanks, that was the reason. With -Wsystem-headers I can r
On Mar 5 17:16, Christian Franke via Cygwin wrote:
>> Roland Mainz via Cygwin wrote:
>>> Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
>>> /usr/include/unistd.h and clang:
>>> snip
>>> $ clang --version
>>> clang ve
> The error is valid because the addition of this very old C++ feature
> took a very long time :-)
Well, it may be so, but adding the parameter names in those prototype on Cygwin
end of things would be a better and less disruptive approach, IMO.
$.02,
Anton Lavrentiev
Contractor NIH/NLM/NCBI
-
On Mar 5 17:16, Christian Franke via Cygwin wrote:
> Roland Mainz via Cygwin wrote:
> > Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
> > /usr/include/unistd.h and clang:
> > snip
> > $ clang --version
> > clang version 8.0.1 (t
Roland Mainz via Cygwin wrote:
Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
/usr/include/unistd.h and clang:
snip
$ clang --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-unknown-windows-cygnus
Thread model: posix
InstalledDir: /usr/bin
Hi!
Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
/usr/include/unistd.h and clang:
snip
$ clang --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-unknown-windows-cygnus
Thread model: posix
InstalledDir: /usr/bin
$ clang -std=gnu17 -Wall
On 20/11/2024 19:34, Jeremy Drake via Cygwin wrote:
I mentioned this briefly on cygwin-patches during the review of the fix
for a deadlock when running under emulation on ARM64 hosts, but I wanted
to discuss it more thoroughly here now that that is merged.
It seems like it would be useful, perha
On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
> IMHO:
>
> if (IsWow64Process2 (GetCurrentProcess (), &emulated, &hosted))
> && emulated != IMAGE_FILE_MACHINE_UNKNOWN)
> if (hosted == IMAGE_FILE_MACHINE_AMD64)
> strcat (sysname, "-WOW64");
> else if (hosted == IMAGE_
On Nov 21 10:15, Jeremy Drake via Cygwin wrote:
> On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
>
> > > i686 x86_64 -WOW64-x64 (or omit arch to match existing?)
> >
> > Just -WOW64
> >
> > For backward compat and it's a sole representative of an intel-intel
> > emulation anyway. I
On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
> > i686x86_64 -WOW64-x64 (or omit arch to match existing?)
>
> Just -WOW64
>
> For backward compat and it's a sole representative of an intel-intel
> emulation anyway. I think we may safely ignore "WOW"
>
> > i686ARM64 -W
On Nov 20 11:34, Jeremy Drake via Cygwin wrote:
> I mentioned this briefly on cygwin-patches during the review of the fix
> for a deadlock when running under emulation on ARM64 hosts, but I wanted
> to discuss it more thoroughly here now that that is merged.
>
> It seems like it would be useful, p
On Wed, 20 Nov 2024, Jeremy Drake via Cygwin wrote:
> CygwinHostSuffix
> Not worth worrying about:
> ARM ARM64 -WOW64-ARM (?)
Oops, this should have been -WOW64-ARM64 since the host is ARM64. But
like I said, this case would never happen anyway.
--
Problem reports: https:/
I mentioned this briefly on cygwin-patches during the review of the fix
for a deadlock when running under emulation on ARM64 hosts, but I wanted
to discuss it more thoroughly here now that that is merged.
It seems like it would be useful, perhaps for stats tracking purposes like
MSYS2 does [1], to
On 8/31/2024 10:04 AM, C,C H via Cygwin wrote:
Hi, Team,
There is a good tool that provides Ctrl+R a powerful interface for search
in shells, and it can support Cygwin environment but currently it requires
manual compilation.
https://dvorka.github.io/hstr/INSTALLATION.html#build-on-cygwin
Is it
Hi, Team,
There is a good tool that provides Ctrl+R a powerful interface for search
in shells, and it can support Cygwin environment but currently it requires
manual compilation.
https://dvorka.github.io/hstr/INSTALLATION.html#build-on-cygwin
Is it possible to provide this tool officially?
Best
> Looking at /usr/include/w32api/minwinbase.h:
> snip
> typedef enum _FILE_INFO_BY_HANDLE_CLASS {
>FileBasicInfo /* is zero? */,
>FileStandardInfo,
>FileNameInfo,
>FileRenameInfo,
>FileDispositionInfo,
>FileAllocationI
On 2024-05-13 07:34, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
*FileNormalizedNameInformation* 44/0x2e is defined in winternl.h
FILE_INFORMATION_CLASS for NtQueryInformationFile:
I see it's defined as 48/0x30 there, though...
Good catch and point!
My computer glasses did not seem to be work
|48|, but works as intended for |24| I assume that the
> > Cygwin header is wrong.
> >
> > Could someone please check the Cygwin header files ?
>
> Could someone please read the enum constant names and classes carefully?
>
> Package w32api-headers:
>
> > Headers
one please read the enum constant names and classes carefully?
Package w32api-headers:
Headers:
snip
$ grep -r FileNormalizedNameInfo /usr/include/
/usr/include/w32api/ddk/wdm.h: FileNormalizedNameInformation,
/usr/include/w32api/minwinbase.h:*FileNormalizedNameInfo*,
/usr/include/w3
t the
value |48|.
Since |GetFileInformationByHandleEx()| gives me error 87 (="Invalid
Parameter") for |48|, but works as intended for |24| I assume that the
Cygwin header is wrong.
Could someone please check the Cygwin header files ?
Headers:
snip
$ grep -r FileNormalizedNameIn
, but couldn't find the repo for
cygwin-devel anywhere.
This error was introduced with the most recent update to cpuset.h.
There is a public-visible mirror of the Cygwin tree at
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin
and the problematic file can be found at
i
to cpuset.h. There is a
public-visible mirror of the Cygwin tree at
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin
and the problematic file can be found at
include/sys/cpuset.h
within.
Your bug report and proposed correction are all we need for the issue you ran
into. I&
I just updated to 3.4.9-1 and compiled some code, and it complained about
cpuset.h.
Specifically, "C++ requires a type specifier for all declarations", and
sure enough, there's no return type on line 52. So I changed my local copy
to the following, and it cleared things up:
#define CPU_ZERO_S(siz
C,C H writes:
> I am looking for making golang and rust codes compiled in cygwin, but it
> seems not easy to build these compilers from scratch.
Rust is a lost cause, there were some discussions among their developers
that went nowhere. Their stance is "we support one compiler for
Windows, that's
On 18.12.2021 09:08, C,C H wrote:
Hi, Team,
I am looking for making golang and rust codes compiled in cygwin, but it
seems not easy to build these compilers from scratch.
likely. Compilers tend to be complex software.
Also for CLANG we are missing recent releases.
If you need help, show some
Hi, Team,
I am looking for making golang and rust codes compiled in cygwin, but it
seems not easy to build these compilers from scratch.
Currently, cygwin does not provide golang and rust compilers.
As far as I know, these popular programming languages are ported to msys2.
Is it possible to pro
Hello!
When I "pip install" python modules for which there are no cygwin
packages, *.dll files are installed below
/usr/local/lib/python3.8/site-packages/.
Since rebaseall does not automatically rebase files under this location,
I had fork failures.
The following patch solved it for me:
$ d
[changed subject]
On 2020-10-14 15:47, Jérôme Froissart wrote:
>> (As evidence of this: the Cygwin command line parser was able to break the
>> command line into arguments correctly, but chose to retain the double
>> quotes.)
>>
>> #include
>>
On Sep 1 11:28, Brian Inglis wrote:
> On 2020-08-31 13:41, Corinna Vinschen wrote:
> > On Aug 31 13:24, Brian Inglis wrote:
> The upstream patch changed only amd64/x86_64 code sequences for multiple
> modules
> including modfl, and left i386/x86 untouched for those modules.
> >>
>
a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>>>>>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
>>>>>>>> Cygwin
>>>>>> ...
>>>>>>>> $ cat test.c
>>>>>>>> #inclu
rinna Vinschen wrote:
> >>>>> On Aug 29 08:52, airplanemath via Cygwin wrote:
> >>>>>> I have two reports. A brief description of the system:
> >>>>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> >>>>>>
planemath via Cygwin wrote:
>>>>>> I have two reports. A brief description of the system:
>>>>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>>>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
>>>>
o reports. A brief description of the system:
> >>>> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> >>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
> >>>> Cygwin
> >> ...
> >>>> $ cat test.c
>
ame -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
>>>> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>> ...
>>>> $ cat test.c
>>>> #include
>>>> #include
>>>> #include
>>>>
>>>
gt; CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
> ...
> >> $ cat test.c
> >> #include
> >> #include
> >> #include
> >>
> >> int main(int argc, char *argv[]) {
> >> long double a, b, c;
> >&
developer snapshot and uploaed it to https://cygwin.com/snapshots/ You
> > need to grab the full tar file and install at least the following files
> > to your installation after backing up the original files from 3.1.7:
> >
> > usr/bin/cygwin1.dll (this is pre-release 3
7:48 x86_64 Cygwin
...
>> $ cat test.c
>> #include
>> #include
>> #include
>>
>> int main(int argc, char *argv[]) {
>> long double a, b, c;
>> char *num_end = NULL;
>> a = b = c = 0.0L;
>> if (argc != 2) {
>> fprintf(
On 2020-08-30 00:23, ASSI wrote:
> Ken Brown via Cygwin writes:
>> OK, so the problem was introduced between 3.1.4 and 3.1.5. It should
>> be pretty easy to bisect and find the culprit. I'll do that tomorrow
>> if no one beats me to it.
>
> The most likely culprit would be this I think:
>
> htt
-08-22 17:48 x86_64 Cygwin
>>
>> The first report:
>>
>> $ cpp /usr/include/threads.h
>> # 1 "/usr/include/threads.h"
>> # 1 ""
>> # 1 ""
>> # 1 "/usr/include/threads.h"
>> /usr/include/threads.h:30:10: f
On 8/30/2020 12:11 PM, Ken Brown wrote:
On 8/29/2020 5:41 PM, Eliot Moss wrote:
It seems the math functions in winsup were not built quite right ...
That's a pretty broad generalization to make based on one reported bug (which Corinna fixed within
24 hours of the report).
I certainly did no
On 8/29/2020 5:41 PM, Eliot Moss wrote:
It seems the math functions in winsup were not built quite right ...
That's a pretty broad generalization to make based on one reported bug (which
Corinna fixed within 24 hours of the report).
Ken
--
Problem reports: https://cygwin.com/problems.ht
On Aug 29 08:52, airplanemath via Cygwin wrote:
> Hello,
>
> I have two reports. A brief description of the system:
> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>
> The first
Ken Brown via Cygwin writes:
> OK, so the problem was introduced between 3.1.4 and 3.1.5. It should
> be pretty easy to bisect and find the culprit. I'll do that tomorrow
> if no one beats me to it.
The most likely culprit would be this I think:
https://sourceware.org/git/?p=newlib-cygwin.git;a
On 8/29/2020 9:21 PM, airplanemath via Cygwin wrote:
Stepping back through Cygwin releases, I find:
$ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
$ ./test.exe 123.456
123.456000 0.456000 123.00
$ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
CYGWIN_NT-10.0 ${HOSTN
E} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64
>> Cygwin
>
> In the future, please use two separate emails for two unrelated bug
> reports.
Will do.
>
>> The first report:
>>
>> $ cpp /usr/include/threads.h
>> # 1 "/usr/include/threads.h"
>> #
On 8/29/2020 1:57 PM, Ken Brown via Cygwin wrote:
>> #include
>> #include
>> #include
>>
>> int main(int argc, char *argv[]) {
>>long double a, b, c;
>>char *num_end = NULL;
>>a = b = c = 0.0L;
>>if (argc != 2)
ls for two unrelated bug reports.
The first report:
$ cpp /usr/include/threads.h
# 1 "/usr/include/threads.h"
# 1 ""
# 1 ""
# 1 "/usr/include/threads.h"
/usr/include/threads.h:30:10: fatal error: machine/_thre
Hello,
I have two reports. A brief description of the system:
$ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
The first report:
$ cpp /usr/include/threads.h
# 1 "/usr/include/threads.h"
# 1 "&
> Hi,
>
>
> If you want to remove old Cygwin installation, you have 2 choices:
>
> - if install has been done for all users, just remove Cygwin folder from
> Windows Explorer
>
> - if install has been done just for current user requiring admin rights, just
> start a new cygwin session with ba
Hi,
If you want to remove old Cygwin installation, you have 2 choices:
- if install has been done for all users, just remove Cygwin folder from
Windows Explorer
- if install has been done just for current user requiring admin rights,
just start a new cygwin session with bash or csh; go to
Dear all,
I am preparing the Cygwin windows package to be installed through Landesk to
all developer's machines. I have managed to prepare a silent installation from
a local repository, but the uninstallation script is not working due to
insufficient permissions:
[INFO] Powershell command: Rem
On 2019-09-11 05:52, Steven Penny wrote:
> On Wed, 11 Sep 2019 16:54:49, Troy Kenah wrote:
>> I used to embed @include junk.awk statements to reduce repetitive code but
>> this no longer works. These were files were not functions, simply code
>> snippets; this is the type of
http://git.savannah.gnu.org/cgit/gawk.git/commit/?id=577ece63770a6c4b5ad00d6998127fb7e85b86b9
I used to embed @include junk.awk statements to reduce repetitive code
but
this no longer works. These were files were not functions, simply code
snippets; this is the type of error I am now seeing:
Clearly
Troy Kenah writes:
> I have a large number of scripts that were using the the igawk script,
> however I have updated my gawk to a newer release that has
> obsoleted/removed the igawk script.
The semantics for @include are different between igawk and "native" gawk
@include (sin
On Wed, 11 Sep 2019 16:54:49, Troy Kenah wrote:
I used to embed @include junk.awk statements to reduce repetitive code but
this no longer works. These were files were not functions, simply code
snippets; this is the type of error I am now seeing:
gawk: get_FY2019Q1OIC.awk:28: @include ".
Hi All,
I have a large number of scripts that were using the the igawk script,
however I have updated my gawk to a newer release that has
obsoleted/removed the igawk script.
I used to embed @include junk.awk statements to reduce repetitive code but
this no longer works. These were files were not
On 10/17/2018 11:28 PM, JonY wrote:
> On 10/17/2018 03:12 PM, Mustafa M wrote:
>> Jon is there anyway we could include an updated version of
>> mingw64-x86_64-binutils and x86_64-w64-mingw32-ld.
>> ( >= v2.30).
>>
>> The issue is with the mingw-264 toolch
On 10/17/2018 03:12 PM, Mustafa M wrote:
> Jon is there anyway we could include an updated version of
> mingw64-x86_64-binutils and x86_64-w64-mingw32-ld.
> ( >= v2.30).
>
> The issue is with the mingw-264 toolchain versions.
Sure, I will do a test version of those soon.
Jon is there anyway we could include an updated version of
mingw64-x86_64-binutils and x86_64-w64-mingw32-ld.
( >= v2.30).
The issue is with the mingw-264 toolchain versions.
Thanks,
Mustafa M
From: JonY<mailto:10wa...@gmail.com>
Sent: Tuesday, October 16, 2018 7:49 PM
To:
On 10/16/2018 09:58 PM, Mustafa M wrote:
> Ok I think the issue has been resolved. There may be some issue with out of
> tree builds with Julia, because with the latest binutils update I can now
> build Julia in tree, but for out of tree configurations.
>
>
>
> Mustafa M
>
Awesome, glad you
behalf of Mustafa M
Sent: Monday, October 15, 2018 7:50:12 PM
To: JonY; cygwin@cygwin.com
Subject: RE: Please include and build version >= 2.3 binutils
Hi Jon,
Please see my comment here
https://github.com/JuliaLang/julia/issues/29488#issuecomment-429956141
Apparently @vtnash seemed to suggest
binutils on Cygwin cross
compilation is failing for me.
Thanks,
Mustafa M
From: JonY<mailto:10wa...@gmail.com>
Sent: Monday, October 15, 2018 7:44 PM
To: cygwin@cygwin.com<mailto:cygwin@cygwin.com>
Cc: Mustafa M<mailto:mu...@outlook.com>
Subject: Re: Please include and bu
On 10/15/2018 07:17 PM, Houder wrote:
> On Mon, 15 Oct 2018 17:53:31, Mustafa M wrote:
> [snip]
>
>> (BTW, for some reason I did not receive any reply email on my outlook) I ha=
>> d to manually reply to your response (not sure why or how to properly fix t=
>> his issue)
>
> Mustafa,
>
> Have yo
On Mon, 15 Oct 2018 17:53:31, Mustafa M wrote:
[snip]
> (BTW, for some reason I did not receive any reply email on my outlook) I ha=
> d to manually reply to your response (not sure why or how to properly fix t=
> his issue)
Mustafa,
Have you subscribed yourself to the mailinglist? (probably not
I’m still having the same linking bug with Julia, despite testing binutils
2.31.1.
(BTW, for some reason I did not receive any reply email on my outlook) I had to
manually reply to your response (not sure why or how to properly fix this issue)
Thanks
--
Problem reports: http://cygwi
On 10/14/2018 02:09 AM, JonY wrote:
> On 10/12/2018 06:05 PM, Mustafa M wrote:
>>
>> Unfournately a bug in binutils
>> (https://github.com/bminor/binutils-gdb/commit/d520d4956e59bd4759932a4d1742828f88c0dd7a)
>> Prevents cross compiling Julia. Please include and build v
On 10/12/2018 06:05 PM, Mustafa M wrote:
>
> Unfournately a bug in binutils
> (https://github.com/bminor/binutils-gdb/commit/d520d4956e59bd4759932a4d1742828f88c0dd7a)
> Prevents cross compiling Julia. Please include and build version >= 2.3
> binutils to resolve this issue.
Unfournately a bug in binutils
(https://github.com/bminor/binutils-gdb/commit/d520d4956e59bd4759932a4d1742828f88c0dd7a)
Prevents cross compiling Julia. Please include and build version >= 2.3
binutils to resolve this issue.
Thanks,
Mustafa
--
Problem reports: http://cygwin.
Ken Brown schreef op 2018-08-16 20:20:
On 8/16/2018 2:11 PM, waterlan wrote:
Ken Brown schreef op 2018-05-14 14:35:
This is a newlib issue that has been fixed:
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=829820af6e5bccefe93485023e93821807fb99b8;hp=e494b560350cabef9412
0.2-1
-O2 -Wall -Wextra -Wno-unused-parameter -Wconversion -Ic3po
-DVERSION=\"6.0.2\" -DVERSION_DATE=\"2018-05-10\" -std=gnu99
-DWCD_UNICODE -DWCD_UNINORM -DENABLE_NLS
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"wcd\"
-I/usr/include/ncursesw
meter -Wconversion-Ic3po
-DVERSION=\"6.0.2\" -DVERSION_DATE=\"2018-05-10\" -std=gnu99
-DWCD_UNICODE -DWCD_UNINORM -DENABLE_NLS
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"wcd\"
-I/usr/include/ncursesw -I/usr/include -DDEBUG=0 -D_LARGEFILE_SOURCE
nused-parameter -Wconversion-Ic3po
> -DVERSION=\"6.0.2\" -DVERSION_DATE=\"2018-05-10\" -std=gnu99
> -DWCD_UNICODE -DWCD_UNINORM -DENABLE_NLS
> -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"wcd\"
> -I/usr/include/ncursesw -I/usr/include -DDE
Hans-Bernhard Bröker writes:
> That does look rather weird. Why would one write that instead of just
> -D_FORTIFY_SOURCE=2 ?
That's what cygport does and Yaakov said he'd copied it from Fedora.
But yes, that _is_ unexpected and it did break stuff elsewehere.
Regards,
Achim.
--
+<[Q+ Matrix-12
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
t;2018-05-10\" -std=gnu99
-DWCD_UNICODE -DWCD_UNINORM -DENABLE_NLS
-DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"wcd\"
-I/usr/include/ncursesw -I/usr/include -DDEBUG=0 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DUNIX -DWCD_USECURSES -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_
Hi,
The C++'s header is not included in the
latest gcc-7.3.0 package. It is included by default in linux distros,
though. It gives access to this new C++17 features:
http://en.cppreference.com/w/cpp/header/filesystem
I believe gcc needs to be compiled with --enable-libstdcxx-filesystem-ts
> -I/usr/include/X11 is incorrect, regardless of case (in)sensitivity.
> X11 headers are namespaced, meaning that you should e.g. #include
> instead of . If your code doesn't do that, then
> you need to fix it.
Ah you are right !
All my includes are already in the form so t
On 2017-12-04 17:14, Laurent Tassan-Got wrote:
> Just consider the simple C program tstl.c
[snip]
> The compilation with the command
> gcc -Wall -O2 -o tstl.exe tstl.c
> is successful and the execution as well.
>
> Now the compilation with:
> gcc -Wall -O2 -o tst
On Oct 24 11:22, FRANCIS Westerman wrote:
> I am trying to do a make on DC3DD code under Cygwin 2.9.0. I last did
> this under Cygwin 2.5.0. when I execute the make for the compiled
> version I get and error that /user/include/cygwin/types.h is missing.
/usr, I hope. /user doesn't
On 10/24/2017 10:22 AM, FRANCIS Westerman wrote:
> I am trying to do a make on DC3DD code under Cygwin 2.9.0. I last did this
> under Cygwin 2.5.0. when I execute the make for the compiled version I get
> and error that /user/include/cygwin/types.h is missing.
>
> The .h fil
I am trying to do a make on DC3DD code under Cygwin 2.9.0. I last did this
under Cygwin 2.5.0. when I execute the make for the compiled version I get and
error that /user/include/cygwin/types.h is missing.
The .h file is not in the directory like it was in 2.5.0 and I would like to
know where
I didn't see it was in /usr/include/qt5 as well. That would be a
standard location. Thanks.
On Fri, Oct 20, 2017 at 2:13 PM, Marco Atzeri wrote:
> On 20/10/2017 20:00, Peter Quiring wrote:
>>
>> Another issue I'm having with mingw is the Qt headers are not in the
&g
On 20/10/2017 20:00, Peter Quiring wrote:
Another issue I'm having with mingw is the Qt headers are not in the
include path.
So I always have to add
-Ic:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\qt5 to get
the Qt headers included.
Is there a correct way to do this?
Thanks.
Another issue I'm having with mingw is the Qt headers are not in the
include path.
So I always have to add
-Ic:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\include\qt5 to get
the Qt headers included.
Is there a correct way to do this?
Thanks.
--
Peter Quiring
--
Problem reports:
can you stop to top post ?
The standard here is bottom post
On 22/03/2017 07:07, Francis ANDRE wrote:
BTW, why installing libpq-devel on Cygwin differs from Linux install
[FrancisANDRE@idefix include ]$uname -a
CYGWIN_NT-6.1-WOW idefix 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin
BTW, why installing libpq-devel on Cygwin differs from Linux install
[FrancisANDRE@idefix include ]$uname -a
CYGWIN_NT-6.1-WOW idefix 2.7.0(0.306/5/3) 2017-02-12 13:13 i686 Cygwin
[FrancisANDRE@idefix ~ ]$find /usr/include -name "libpq*.*"
/usr/include/libpq/libpq-fs.h
/usr/inc
On 20/03/2017 11:26, Francis ANDRE wrote:
I am not asking for changing the packaging or the package name... just
to display it in the window when searching for "postgres"
the search is based on the package name
Le 20/03/2017 à 11:01, Marco Atzeri a écrit :
reply on mailing list.
On 20/03
I am not asking for changing the packaging or the package name... just
to display it in the window when searching for "postgres"
Le 20/03/2017 à 11:01, Marco Atzeri a écrit :
> reply on mailing list.
>
> On 20/03/2017 10:26, Francis ANDRE wrote:
>> It would be nice to add the libpq-devel package
reply on mailing list.
On 20/03/2017 10:26, Francis ANDRE wrote:
It would be nice to add the libpq-devel package when looking for
postgres as it is missing (see below)
the package is called in the same way on major Linux
distributions.
I will not change it.
Regards
Marco
--
Problem report
%2fcygwin.mirror.constant.com%2f/x86/release/postgresql/postgresql-devel/postgresql-devel-9.6.2-1.tar.xz
but none of these installations provide the libpq-fe.h include.
[FrancisANDRE@idefix ~ ]$find /usr/include -name "*libpq-*.*"
/usr/include/postgresql/server/libpq/libpq-be.h
/usr/include/postgresql/se
On 23/12/2015 04:30, ravi r wrote:
When the configure script of RQuantLib package tries to check for boost
development files by compiling this program
$ cat > /tmp/conftest.cpp <<-EOF
#include
#include
#include
#include
When the configure script of RQuantLib package tries to check for boost
development files by compiling this program
$ cat > /tmp/conftest.cpp <<-EOF
#include
#include
#include
#include
int main () {
;
t; >
> > Thanks and sorry for the false alarm.
> >
> > Andrew Ritz
>
> Please don't top-post.
>
> >
> > On 2015-12-07 12:08, Corinna Vinschen wrote:
> >>
> >> On Dec 7 11:03, Andrew Ernest Ritz wrote:
> >>>
;
> Andrew Ritz
Please don't top-post.
>
> On 2015-12-07 12:08, Corinna Vinschen wrote:
>>
>> On Dec 7 11:03, Andrew Ernest Ritz wrote:
>>>
>>> I get the following message when compiling programs on windows 10 -
>>> /usr/include/string.
ndrew Ernest Ritz wrote:
I get the following message when compiling programs on windows 10 -
/usr/include/string.h:108: syntax error at token '__asm__'. Is this
something to worry about?
Works for me. There may be some collision with a definition in your
llocal build environment. Ca
On Dec 7 11:03, Andrew Ernest Ritz wrote:
> I get the following message when compiling programs on windows 10 -
> /usr/include/string.h:108: syntax error at token '__asm__'. Is this
> something to worry about?
Works for me. There may be some collision with a definition i
On 18 August 2015 at 11:10, Corinna Vinschen wrote:
> On Aug 17 21:46, Yaakov Selkowitz wrote:
>> * libc/include/sys/signal.h [__CYGWIN__]: include
>> if compiling for POSIX.1-2008.
>>
>> Signed-off-by: Yaakov Selkowitz
>> ---
>> How about thi
1 - 100 of 387 matches
Mail list logo
