cygwin announce mail went missing?

[JonY]

Hi,

I sent an announcement about mingw64-*-headers and runtime update a few
days ago, but I don't see it. Did it go missing?



signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: w32api-{headers,runtime}-3.0.0-1, mingw64-*-headers-3.0.0-1, mingw64-*-runtime-3.0.0-1

[JonY]

I have just updated the CRT and runtime libraries for the mingw-w64
cross compilers, along with the w32api for Cygwin 32bit and 64bit.

mingw64-*-headers-3.0.0-1
mingw64-*-runtime-3.0.0-1
w32api-{headers,runtime}-3.0.0-1

The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-mingw32 for autotools based source packages to build
for Windows.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: cygwin announce mail went missing?

[JonY]

On 9/26/2013 01:20, Andrey Repin wrote:
> Greetings, JonY!
> 
>> I sent an announcement about mingw64-*-headers and runtime update a few
>> days ago, but I don't see it. Did it go missing?
> 
> Pathed on this side all fine.
> 

Odd, I specifically disabled the gmail spam filter. If it is really out
I guess it is fine.





signature.asc
Description: OpenPGP digital signature

Re: i686-w64-mingw32-gcc of cygwin64 is broken

[JonY]

On 9/26/2013 19:03, Frédéric Bron wrote:
>> Compiled binary seems to crash here.
>> I updated mingw64 runtime/headers yesterday.
>>
>> $ echo "main(){}" >t.c && i686-w64-mingw32-gcc t.c -o t
>> $ ./t
>> Segmentation fault
> 
> These have been updated:
> mingw64-*-headers-3.0.0-1
> mingw64-*-runtime-3.0.0-1
> w32api-{headers,runtime}-3.0.
> 0-1
> 
> I wonder if the cross-compiler it-self should not be rebuilt.
> 

Normally no, as there aren't any major ABI changes. I need to investigate.






signature.asc
Description: OpenPGP digital signature

Re: winbase.h issue

[JonY]

On 9/26/2013 18:47, Noboru Uchida wrote:
> When I try the following:
> 
> $ echo "#include " >foo.cc && c++ -c foo.cc
> 
> I get tons of redefinition errors on Interlocked functions in winbase.h.
> 

Looks like it happens only in C++ mode.





signature.asc
Description: OpenPGP digital signature

Re: winbase.h issue

[JonY]

On 9/26/2013 21:07, JonY wrote:
> On 9/26/2013 18:47, Noboru Uchida wrote:
>> When I try the following:
>>
>> $ echo "#include " >foo.cc && c++ -c foo.cc
>>
>> I get tons of redefinition errors on Interlocked functions in winbase.h.
>>
> 
> Looks like it happens only in C++ mode.
> 

Adding mingw-w64 list.
Here are some of the errors:

> /usr/include/w32api/winbase.h: In function ‘unsigned int 
> _InterlockedIncrement(volatile unsigned int*)’:
> /usr/include/w32api/winbase.h:2925:33: error: redefinition of ‘unsigned int 
> _InterlockedIncrement(volatile unsigned int*)’
>FORCEINLINE unsigned __LONG32 InterlockedIncrement (unsigned __LONG32 
> volatile *Addend) { return (unsigned __LONG32) InterlockedIncrement 
> ((volatile __LONG32 *) Addend); }
>  ^
> /usr/include/w32api/winbase.h:2924:24: error: ‘unsigned int 
> _InterlockedIncrement(volatile unsigned int*)’ previously defined here
>FORCEINLINE unsigned InterlockedIncrement (unsigned volatile *Addend) { 
> return (unsigned) InterlockedIncrement ((volatile __LONG32 *) Addend); }
> ^
> /usr/include/w32api/winbase.h: In function ‘unsigned int 
> _InterlockedDecrement(volatile unsigned int*)’:
> /usr/include/w32api/winbase.h:2930:33: error: redefinition of ‘unsigned int 
> _InterlockedDecrement(volatile unsigned int*)’
>FORCEINLINE unsigned __LONG32 InterlockedDecrement (unsigned __LONG32 
> volatile *Addend) { return (unsigned __LONG32) InterlockedDecrement 
> ((volatile __LONG32 *) Addend); }
>  ^
> /usr/include/w32api/winbase.h:2929:24: error: ‘unsigned int 
> _InterlockedDecrement(volatile unsigned int*)’ previously defined here
>FORCEINLINE unsigned InterlockedDecrement (unsigned volatile *Addend) { 
> return (unsigned __LONG32) InterlockedDecrement ((volatile __LONG32 *) 
> Addend); }
> ^


So the declaration was:
> extern "C++" {
>   FORCEINLINE unsigned InterlockedIncrement (unsigned volatile *Addend) { 
> return (unsigned) InterlockedIncrement ((volatile __LONG32 *) Addend); }
>   FORCEINLINE unsigned __LONG32 InterlockedIncrement (unsigned __LONG32 
> volatile *Addend) { return (unsigned __LONG32) InterlockedIncrement 
> ((volatile __LONG32 *) Addend); }

Cygwin64 g++ wasn't happy with that. Cygwin 32bit mode is fine though.




signature.asc
Description: OpenPGP digital signature

Re: winbase.h issue

[JonY]

On 9/26/2013 21:16, JonY wrote:
> On 9/26/2013 21:07, JonY wrote:
>> On 9/26/2013 18:47, Noboru Uchida wrote:
>>> When I try the following:
>>>
>>> $ echo "#include " >foo.cc && c++ -c foo.cc
>>>
>>> I get tons of redefinition errors on Interlocked functions in winbase.h.
>>>
>>
>> Looks like it happens only in C++ mode.
>>
> 
> Adding mingw-w64 list.

A fix has been committed, will make a new release tomorrow.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: w32api-headers-3.0.0-2 and mingw64-i686-runtime-3.0.0-2 (x86_64)

[JonY]

I have just updated the w32api-headers and mingw64-i686-runtime package
for 64bit Cygwin.

The new w32api-headers should fix the winbase.h conflicts, while the new
runtime is a rebuild of -1 to fix the segfault issues due to a mistake
in the first release.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: w32api-headers-3.0.0.-1 in question

[JonY]

On 10/4/2013 18:02, Denis Excoffier wrote:
> Hello,
> 
> I use cygwin 32 bits, last snapshot.
> 
> Since the last update of
> - mingw64-i686-headers-3.0.0-1
> - mingw64-i686-runtime-3.0.0-1
> - w32api-headers-3.0.0-1
> - w32api-runtime-3.0.0-1
> (see http://cygwin.com/ml/cygwin-announce/2013-09/msg00018.html)
> 
> i'm no longer able to compile the last cygwin snapshot (20130925).
> With the Previous issues of these packages (3.0b_svn5935), all is ok.
> 

Corinna, cgf, last time, Kai mentioned that these were added recently,
Cygwin might have been declaring it on its own.




signature.asc
Description: OpenPGP digital signature

Re: Hooks do not work?

[JonY]

On 10/26/2013 14:32, niXman wrote:
> compiled as:
> gcc hook.c -shared -oopenhook.dll
> gcc main.c -omain
> 
> run as:
> LD_PRELOAD=/home/niXman/openhook.dll ./main
> 
> But a can't see the output.
> What I am doing wrongly?
> 

LD_PRELOAD is an ELF interpreter feature and bares no effect on Windows,
so you are out of luck.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.2-1 (x86_64)

[JonY]

I have updated gcc for 64bit Cygwin to the latest released version.

There aren't any Cygwin specific changes introduced since 4.8.1, so it
should work similarly.

The last 32bit 4.8.x build didn't go so well, will try again this weekend.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



signature.asc
Description: OpenPGP digital signature

Re: ATTENTION GCC PACKAGE MAINTAINER - Re: GCC: core, g++ version mismatch

[JonY]

On 10/30/2013 22:42, marco atzeri wrote:
> Il 10/30/2013 2:52 PM, Christopher Faylor ha scritto:
>> On Wed, Oct 30, 2013 at 08:31:39AM -0500, Trent Bradley wrote:
>>> I didn't see this mentioned anywhere yet, but there appears to be a
>>> version mismatch between gcc-core and gcc-g++.
>>>
>>> gcc-core is listed as having 4.8.2-1 available, gcc-g++ is still at
>>> 4.8.1-3.
>>>
>>> Updating gcc-core (and libgcc1 with it) breaks all build attempts for
>>> me.
>>>
>>> Cygwin64: 2.830, Win64
>>
>> This is a pretty serious packaging bug.  JonY please fix ASAP.
> 
> also source package seems wrong
> http://cygwin.com/packages/x86_64/gcc/
> 


Seems like something went wrong when uploading files with "++" in the
name to the new sftp at cygwin.com.

Strange that I did not get any errors on my end, will upload again.





signature.asc
Description: OpenPGP digital signature

Re: ATTENTION GCC PACKAGE MAINTAINER - Re: GCC: core, g++ version mismatch

[JonY]

On 10/31/2013 00:09, Christopher Faylor wrote:.
> 
> I restrict the filenames that can be uploaded and neglected to add '+'.
> I just added it now so you will have to upload those files again.  Sorry
> for the inconvenience.
> 

Done, reuploaded.

>> Strange that I did not get any errors on my end, will upload again.
> 
> You should have gotten an error.  I noticed errors myself when trying
> to upload a !email file because, for a time, '!' wasn't supported either.
> 

Is this supposed to be placed in the root directory?




signature.asc
Description: OpenPGP digital signature

Re: upset messages

[JonY]

On 11/9/2013 18:45, Corinna Vinschen wrote:
> On Nov  9 10:36,  wrote:
>> upset: *** /var/ftp/pub/cygwin/x86/setup.ini: error - package gcc-java 
>> requires nonexistent package java-ecj
>> upset: *** /var/ftp/pub/cygwin/x86/setup.ini: error - package gcc-java 
>> requires package java-ecj which has no "curr" binary
> 
> I silenced this message for now by removing the nonexisting java-ecj from
> gcc/gcc-java/setup.hint, but this looks wrong.
> 

Thanks, already asked Yaakov to put up gcc-ecj, since he already has it
in Cygwin ports.

What about the odd gcc4 warning?




signature.asc
Description: OpenPGP digital signature

Re: upset messages

[JonY]

On 11/10/2013 00:51, Corinna Vinschen wrote:
> On Nov  9 21:20, JonY wrote:
>> On 11/9/2013 18:45, Corinna Vinschen wrote:
>>> On Nov  9 10:36,  wrote:
>>>> upset: *** /var/ftp/pub/cygwin/x86/setup.ini: error - package gcc-java 
>>>> requires nonexistent package java-ecj
>>>> upset: *** /var/ftp/pub/cygwin/x86/setup.ini: error - package gcc-java 
>>>> requires package java-ecj which has no "curr" binary
>>>
>>> I silenced this message for now by removing the nonexisting java-ecj from
>>> gcc/gcc-java/setup.hint, but this looks wrong.
>>>
>>
>> Thanks, already asked Yaakov to put up gcc-ecj, since he already has it
>> in Cygwin ports.
> 
> Guess you mean java-ecj...
> 

Yes, java-ecj, sorry.

>> What about the odd gcc4 warning?
> 
> Should be fixed.  I removed gcc4/libstdc++-devel.
> 

Thanks.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.2-1 (x86)

[JonY]

gcc-4.8.x is finally out for 32bit Cygwin. This should fix the python
crash issue.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-1 (x86)

[JonY]

On 11/10/2013 12:34, marco atzeri wrote:
> Il 11/10/2013 4:31 AM, JonY ha scritto:
>>
>> gcc-4.8.x is finally out for 32bit Cygwin. This should fix the python
>> crash issue.
>>
> 
> ok,
> but why is pulling python3 as dependency ?
> 
> python3(3.2.3-1)
> Py3K language interpreter
> Required by: gcc-g++, gcc-java
> 

Ugh, must be the python script for gdb.





signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-1 (x86)

[JonY]

On 11/10/2013 12:34, marco atzeri wrote:
> Il 11/10/2013 4:31 AM, JonY ha scritto:
>>
>> gcc-4.8.x is finally out for 32bit Cygwin. This should fix the python
>> crash issue.
>>
> 
> ok,
> but why is pulling python3 as dependency ?
> 
> python3(3.2.3-1)
> Py3K language interpreter
> Required by: gcc-g++, gcc-java
> 

Done, removed.

Yaakov, is there a way to tell Cygport about false positives? If not,
feature request! :)





signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-1 (x86_64)

[JonY]

On 11/8/2013 02:21, Eric Lilja wrote:
> On 2013-10-29 23:40, JonY wrote:
>>
>> The last 32bit 4.8.x build didn't go so well, will try again this
>> weekend.
>>
> 
> Any news regarding 32-bit 4.8.x? Thanks for working on this!

32bit version is now out.





signature.asc
Description: OpenPGP digital signature

Re: python aborts

[JonY]

On 11/11/2013 20:59, Corinna Vinschen wrote:
>> I pinged the upstream maintainer who probably wasn't aware of this yet.
> 
> The patche is checked in upstream.  JonY,  any chance for an updated
> gcc toolchain soon?
> 

The 4.8.2-1 release should already contain this patch.





signature.asc
Description: OpenPGP digital signature

Re: C++11 program link failure under GCC 4.8.2-1

[JonY]

On 11/12/2013 06:17, JonY wrote:
> On 11/12/2013 05:17, Yucong Sun wrote:
>> Hi,
>>
>> I'm trying to compile a program under cygwin with latest gcc 4.8.2,
>> the program compiles fine, but link failed. I'm suspecting this has
>> something todo with libstdc++ but I couldn't find any document on how
>> to check libstdc++ version (cygwin setup claim it is version 4.8.2
>> already).
>>
> 
> I'm not sure either, could you ask gcc-help instead?
> 
> 

963e2a697c3a1a7d036d975b07f4c408bbd1cb2d *libstdc++.dll.a
f4dfadfddade3aceaf4852cd5db31372ab7ef0d1 *libstdc++.a

Is your sha1sum matching mine for 4.8.2?




signature.asc
Description: OpenPGP digital signature

Re: C++11 program link failure under GCC 4.8.2-1

[JonY]

On 11/12/2013 07:37, Yucong Sun wrote:
> Yes, the sha1 matches.
> 
> sunyc@sunyc-wks /lib/gcc/i686-pc-cygwin/4.8.2
> $ sha1sum.exe libstdc++.*
> f4dfadfddade3aceaf4852cd5db31372ab7ef0d1 *libstdc++.a
> 963e2a697c3a1a7d036d975b07f4c408bbd1cb2d *libstdc++.dll.a
> 
> Also I couldn't find GLIB_xxx version number in libstdc++.a

Those are ELF versioning, Windows does not have it.




signature.asc
Description: OpenPGP digital signature

Re: C++11 program link failure under GCC 4.8.2-1

[JonY]

On 11/12/2013 10:33, Yucong Sun wrote:
> I've tried on both 32bit and 64bit clean cygwin install, the result is
> same. Something is wrong with cygwin's gcc.
> 
> my configure script by default uses g++ --std=c++11, this still have
> problem of " no snprintf " , after I replace all snprintf() with
> sprintf() , I've met the same linkage problem again.
> 

Something else is very wrong.

> g++ --std=gnu++0x "fixes" the snprintf problem, but it still have same
> linkage problem.
> 

Please make a minimalist case, I've tried some basic C++11 features but
I don't get such errors.




signature.asc
Description: OpenPGP digital signature

Re: C++11 program link failure under GCC 4.8.2-1

[JonY]

On 11/13/2013 02:35, Yucong Sun wrote:
> Good new! I've found the link failure issue, it is caused by  "-rdynamic"
> 
> sunyc@sunyc-wks ~
> $ cat 2.cc
> #include 
> 
> struct tick_event {
> int i;
> };
> 
> int main() {
> std::deque list;
> 
> tick_event *a = new tick_event;
> list.push_back(a);
> return 0;
> }
> 
> sunyc@sunyc-wks ~
> $ g++ -c --std=c++11 -O3 -flto 2.cc -o 2.o
> 
> sunyc@sunyc-wks ~
> $ g++ --std=c++11 -flto -D_GNU_SOURCE -rdynamic -fno-omit-frame-pointer 
> -D_GNU_
> SOURCE -march=native  -O3 2.o -o a
> Cannot export 
> _ZNSt5dequeIP10tick_eventSaIS1_EE16_M_push_back_auxIJRKS1_EEEvDpOT
> _: symbol wrong type (4 vs 3)
> collect2: error: ld returned 1 exit status
> 
> 
> sunyc@sunyc-wks ~
> $ g++ --std=c++11 -flto -D_GNU_SOURCE -fno-omit-frame-pointer -D_GNU_SOURCE 
> -ma
> rch=native  -O3 2.o -o a
> 
> sunyc@sunyc-wks ~
> $
> 
> Hope it would help you nail the problem.
> 

-rdynamic shouldn't do anything on Windows, I guess using ELF specific
arguments can break things.
> 
> And Here's the test case for snprintf & c++11
> 
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-cygwin/4.8.2/lto-wrapper.exe
> Target: x86_64-pc-cygwin
> Configured with: 
> /cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-1/src/gcc-4.8.2/co
> nfigure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-1/src/gcc-4.8.2 
> --
> prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
> --libexecdi
> r=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc 
> --lib
> dir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc -C 
> --build=x86
> _64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin 
> --without-libico
> nv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc 
> --enab
> le-static --enable-version-specific-runtime-libs --enable-bootstrap 
> --disable-__
> cxa_atexit --with-dwarf2 --with-tune=generic 
> --enable-languages=c,c++,fortran,lt
> o,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic 
> --ena
> ble-libgomp --disable-libitm --enable-libquadmath 
> --enable-libquadmath-support -
> -enable-libssp --enable-libgcj-sublibs --disable-java-awt --disable-symvers 
> --wi
> th-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as 
> --with-cloog-incl
> ude=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix 
> --
> with-system-zlib
> Thread model: posix
> gcc version 4.8.2 (GCC)
> 
> 
> sunyc@sunyc-wks ~
> $ cat 1.cc
> #include 
> 
> int main() {
>  char out[255];
>  snprintf(out, sizeof(out), "%d", 1);
>  return 1;
> }
> 
> sunyc@sunyc-wks ~
> $ g++ --std=c++11 1.cc
> 1.cc: In function ‘int main()’:
> 1.cc:5:36: error: ‘snprintf’ was not declared in this scope
>   snprintf(out, sizeof(out), "%d", 1);
> ^
> 
> sunyc@sunyc-wks ~
> $ g++ --std=gnu++0x 1.cc
> 
> sunyc@sunyc-wks ~
> $ ls -lah a.exe
> -rwxr-xr-x 1 sunyc None 62K Nov 12 10:21 a.exe
> 
> Cheers.
> 

Right now, it is guarded by:
#if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L)

Which means non-strict mode and C99 mode, snprintf was not part of
C++03. I guess (__cplusplus >= 201103L) needs to be added to newlib.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: mingw64-*-gcc-4.8.2-1

[JonY]

This update includes:

Update:
mingw64-*-gcc-4.8.2-1

*** NOTES ***
gcc-4.8.x is built as is from FSF sources.

C++11 std::to_string is now supported. Caveat: C++11 mode implies C99
mode vsnprintf and vsnwprintf, any calls to these will be redirected to
__mingw_* variants, not to msvcrt. That means no more using "%I64d" in
C++11 mode, use "%lld" or inttypes.h macros instead.

**

The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-mingw32 for autotools based source packages to build
for Windows.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)

[JonY]

4.8.2-2 is a rebuilt of -1 with an additional --libexecdir=/usr/lib,
this should fix reports of spawn failures when called with /bon/gcc.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)

[JonY]

On 12/10/2013 18:52, Achim Gratz wrote:
> JonY <10walls  gmail.com> writes:
>> 4.8.2-2 is a rebuilt of -1 with an additional --libexecdir=/usr/lib,
>> this should fix reports of spawn failures when called with /bon/gcc.
> 
> This update breaks libquadmath0 because the library hasn't been uploaded
> correctly.


OK, I see something called libquadmath0gcc-ada, my cygport file is broken.





signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86)

[JonY]

On 12/11/2013 02:07, Corinna Vinschen wrote:
> On Dec 10 18:32, Achim Gratz wrote:
>> Corinna Vinschen writes:
>>> Does it make sense to remove the libquadmath0gcc-ada package entirely
>>> for now?
>>
>> Yes, the whole libquadmath0gcc-ada directory including the files in it.
>> Then setup.ini should have the 4.8.2-1 package version of libquadmath as
>> current until it gets replaced with the -2 or -3 version.
> 
> Jon?  That's ok with you?

I just reuploaded -2 and deleted the stray libquadmath0gcc-ada. Both new
and existing users should not notice any big difference other than an
update.





signature.asc
Description: OpenPGP digital signature

Re: /bin before /usr/bin makes i686-w64-mingw-gcc fail

[JonY]

On 1/11/2014 04:43, Thomas Nilsson wrote:
> During some unfortunate events I happened to get /bin as the first
> directory in my PATH. This caused the gcc cross compilers to fail with:
> 
> i686-w64-mingw32-gcc: error: spawn: No such file or directory

This is a known problem, don't do that. Will be fixed on next release.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: w32api-{headers,runtime}-3.1.0-1, mingw64-*

[JonY]

New release for both 32bit and 64bit Cygwin:

mingw64-*-headers-3.1.0-1
mingw64-*-runtime-3.1.0-1
mingw64-*-winpthreads-3.1.0-1
mingw64-*-gcc-4.8.2-2
w32api-{headers,runtime}-3.1.0-1

This release includes some deadlock fix for winpthreads and workarounds
for intrin.h C++ linkages.

The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-mingw32 for autotools based source packages to build
for Windows.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86_64)

[JonY]

I have rebuilt gcc for 64bit Cygwin, this release includes ADA support.

KNOWN REGRESSIONS:
The compiler internals are in /usr/libexec rather than in /usr/lib. This
is a mistake on my part. Expect a fixed rebuild in 2-4 weeks time.


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: Re> [ANNOUNCEMENT] Updated: gcc-4.8.2-2 (x86_64)

[JonY]

On 2/15/2014 01:40, Angelo Graziosi wrote:
> JonY wrote:
>> KNOWN REGRESSIONS:
>> The compiler internals are in /usr/libexec rather than in /usr/lib. This
>> is a mistake on my part. Expect a fixed rebuild in 2-4 weeks time.
> 
> On the mirrors I find tar-balls (still -2) with recent timestamps,
> around Feb. 12, 2014.
> 
> Does this mean that the rebuild fixing the "known regressions" has been
> done?
> 

No, I accidentally put up the same tarballs again, not sure what I was
thinking, lost track of the release numbers. Anyway, -3 upload is in
progress.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.2-3 (x86_64)

[JonY]

I have rebuilt gcc for 64bit Cygwin, this time, internals are in
/usr/lib to get around failures when gcc is called from /bin.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.





signature.asc
Description: OpenPGP digital signature

Re: Compiled executables requiring admin rights - different results between MinGW host type

[JonY]

On 3/13/2014 02:41, Corinna Vinschen wrote:
> So, if you have a bit of time, it would be nice to get new
> mingw64-i686-binutils and mingw64-x86_64-binutils packages (as well
> as a new Cygwin binutils, but cgf already knows about this).
> 

Sure, I'll get to it this weekend.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.0.5a026fc-1 (x86/x86_64)

[JonY]

Version 2.24.0.0.5a026fc-1 of mingw64-*-binutils have been uploaded.

This version includes automatic manifest generation to prevent UAC from
automatically called based on executable file name.

For the 64bit target, the assembler includes a new -Wa,-mbig-obj option
to allow objects with up to 2**31 sections. This is useful for C++ code
built with -ffunction-section and -fdata-section.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: binutils-2.24.51-2 (x86/x86_64)

[JonY]

On 3/27/2014 16:55, Angelo Graziosi wrote:
> CGF wrote
>> I don't support those packages so there
>> is no need to pollute the thread with pointless observations
> 
> It was just to remember thet Cygwin distro needs alsot those upgrades...
> 
> I suppose that JonY reads also this thread..
> 

I'll upload for mingw-w64 this weekend.





signature.asc
Description: OpenPGP digital signature

Re: does using mingw-gcc require to compile all libraries with it?

[JonY]

On 3/28/2014 17:00, ton...@free.fr wrote:
> Hello, 
> I just installed mingw-gcc-4.7.3 on top of my cygwin installation. 
> 
> Trying to build a library that needs openssl lib, I get undefined references 
> to __errno and __getreent from this library. 
> - I understood those variables are from cygwin1.dll, is it correct? 
> - does this mean that I should build libcrypto on my own from sources using 
> mingw-gcc also ? (and same for any other lib currently available in my cygwin 
> installation? 
> - or am I missing some option in my build ? 
> 

Yes, you have to build with mingw-gcc, you mustn't use any libraries
built by Cygwin gcc, since those are for Cygwin, not mingw.

> Note: I get the same lib correctly built with : 
> - mingw standalone toolchain, but I'd rather use mingw-gcc in cycgwin if 
> possible. 
> - cygwin's gcc, but running a JNI lib that uses printf or other stdio stuff 
> hangs the VM. 
> 

Do not mix Cygwin with native code, use the mingw-gcc (cross compiler
from cygwin) with JNI instead.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)

[JonY]

Version 2.24.0.1.acd6540-1 of mingw64-*-binutils have been uploaded.

This is a bug fix release from git.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)

[JonY]

On 4/2/2014 01:13, Denis Excoffier wrote:
> On 2014-03-30 16:58, JonY wrote:
> 
>>
>> Version 2.24.0.1.acd6540-1 of mingw64-*-binutils have been uploaded.
>>
>> This is a bug fix release from git.
>>
> This must be more than a simple bug fix release.
> 
> I’m talking about the
> mingw64-x86_64-binutils-2.24.0.1.acd6540-1.tar.xz,
> which does not contain usr/bin/x86_64-w64-mingw32-ld.exe
> although mingw64-x86_64-binutils-2.24.0.0.5a026fc-1.tar.xz did.
> 
> This prevents me from compiling the last cygwin snapshot (target cyglsa64.dll
> fails because of ‘ld’ missing).
> 
> More than that, the new package contains usr/share/info/binutils.info
> (which the previous one didn’t), but this file is already provided
> by the binutils-2.24.51-2 package (with the .gz suffix, i must
> however recognize).
> 
> Please someone to confirm that this new mingw64-x86_64-binutils
> package is indeed ok.
> 

This problem is only affecting the 32bit Cygwin release, which is using
the same cygport and source, which is very strange. Anyway, please roll
back for now.






signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)

[JonY]

On 4/2/2014 06:10, JonY wrote:
> On 4/2/2014 01:13, Denis Excoffier wrote:
>> On 2014-03-30 16:58, JonY wrote:
>>
>>>
>>> Version 2.24.0.1.acd6540-1 of mingw64-*-binutils have been uploaded.
>>>
>>> This is a bug fix release from git.
>>>
>> This must be more than a simple bug fix release.
>>
>> I’m talking about the
>> mingw64-x86_64-binutils-2.24.0.1.acd6540-1.tar.xz,
>> which does not contain usr/bin/x86_64-w64-mingw32-ld.exe
>> although mingw64-x86_64-binutils-2.24.0.0.5a026fc-1.tar.xz did.
>>
>> This prevents me from compiling the last cygwin snapshot (target cyglsa64.dll
>> fails because of ‘ld’ missing).
>>
>> More than that, the new package contains usr/share/info/binutils.info
>> (which the previous one didn’t), but this file is already provided
>> by the binutils-2.24.51-2 package (with the .gz suffix, i must
>> however recognize).
>>
>> Please someone to confirm that this new mingw64-x86_64-binutils
>> package is indeed ok.
>>
> 
> This problem is only affecting the 32bit Cygwin release, which is using
> the same cygport and source, which is very strange. Anyway, please roll
> back for now.
> 

I am told that this is happening due to a bug in an earlier binutils
release, though it still seems to be happening with -2.

The error, for reference when linking ld.exe:
default-manifest.o: file not recognized: File format not recognized




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)

[JonY]

On 4/2/2014 18:04, Corinna Vinschen wrote:
>>
>> I am told that this is happening due to a bug in an earlier binutils
>> release, though it still seems to be happening with -2.
>>
>> The error, for reference when linking ld.exe:
>> default-manifest.o: file not recognized: File format not recognized
> 
> The default-manifest.o file in the latest x86 binutils package is ok.
> It's no problem to link an application with it.
> 
> Are you accidentally using another default-manifest.o file while linking
> ld, for instance, due to -L paths on the command line?
> 

No, it is in the build directory:

$ x86_64-w64-mingw32-nm default-manifest.o
 d .rsrc

The /usr/lib has the correct arch though.  I think it should be compiled
as default-manifest-new.o like ld-new so it does not accidentally
interfere with the build.

I'm not too familiar how to change the Makefile logic to do this though,
I'll write a bit to the binutils list.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.1.acd6540-1 (x86/x86_64)

[JonY]

On 4/7/2014 06:11, m0viefreak wrote:
> 
> Looks like it's not searching for the default-manifest.o in the correct
> include paths.
> 
> The mingw file resides in
> /usr/{x86_64,i686}-w64-mingw32/lib/
> 
> Maybe it should be in
> /usr/{x86_64,i686}-w64-mingw32/sys-root/mingw/lib/
> 

Yes, this is apparently the fix, copy, move, link it, either will work.
Looks like -3 will be coming soon.






signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: mingw64-*-binutils-2.24.0.3.85cf705-1 (x86/x86_64)

[JonY]

Version 2.24.0.3.85cf705-1 of mingw64-*-binutils have been uploaded.

This removes the previously included default-manifest.o file support. It
is now in its own package. Support for automatically linking it is being
moved into GCC instead.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.





signature.asc
Description: OpenPGP digital signature

Re: GIT (was: Coverity Scan)

[JonY]

On 4/26/2014 07:27, Andrey Repin wrote:
> This is exactly what makes me dislike it strongly. This, and idiotic model of
> copying whole repository to my machine, when I only want to glance at the
> source code, and find the culprit of my current issues.
> I've spent 3 hours downloading a 200Mb repo of a project, where the Subversion
> client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what an
> idiotic weight I pulled and went to google to see if it can be done better.
> And "fine control" doesn't mix with "project consistency" at all.
> Subversion is aimed at versioning of a whole project, in a supposedly
> consistent state at each version. What can be more "fine" than this, is beyond
> my understanding.

git clone --depth 1 if you don't care about history.

> You can still commit separate files from working copy, though, but this
> practice is discouraged for the greater good of the project you develop.
> 

Don't you need to git add individual files to mark for commit? Won't you
get into the same problems if you forgot to commit files in SVN?





signature.asc
Description: OpenPGP digital signature

ioctl crash in mpg123

[JonY]

Hi,

I am debugging a crash in Cygwin 1.7.29-2 ioctl but I am not familiar
with the OSS sounds API. I traced the ioctl calls and made this example,
is it supposed to work?

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(){
  int fmt = AFMT_MU_LAW;
  int chan = 0;
  int fd = open("/dev/dsp", O_WRONLY);
  ioctl(fd, SNDCTL_DSP_RESET, NULL);
  ioctl(fd, SNDCTL_DSP_RESET, NULL);
  ioctl(fd, SNDCTL_DSP_RESET, NULL);
  ioctl(fd, SNDCTL_DSP_SETFMT, &fmt);
  ioctl(fd, SNDCTL_DSP_STEREO, &chan); /* crashes here */
  close(fd);
  exit(0);
}



signature.asc
Description: OpenPGP digital signature

Re: ioctl crash in mpg123

[JonY]

On 5/2/2014 23:15, Christopher Faylor wrote:
> On Fri, May 02, 2014 at 07:16:25PM +0800, JonY wrote:
>> Hi,
>>
>> I am debugging a crash in Cygwin 1.7.29-2 ioctl but I am not familiar
>> with the OSS sounds API. I traced the ioctl calls and made this example,
>> is it supposed to work?
> 
> If you're asking if Cygwin is supposed to SEGV in certain situations the
> answer is "no".
> 
> This should be fixed in the next snapshot.
> 
> Thanks for the test case.
> 
> cgf
> 

Thanks for fixing this quickly!




signature.asc
Description: OpenPGP digital signature

Re: gcc-4.9.0 patch status

[JonY]

On 5/8/2014 17:20, Rainer Emrich wrote:
> I try to bootstrap gcc-4.9.0 for cygwin 64-bit, but this fails in adalib.
> AFAIS upstream are still some patches missing which are in the gcc-4.8.2-3 
> source.
> 
> Does anybody knows the status for these patches?
> 

I am working on them, albeit slowly, you can look at the current 4.8.x
patches, some need rebasing.




signature.asc
Description: OpenPGP digital signature

Re: gcc-4.9.0 patch status

[JonY]

On 5/8/2014 17:43, JonY wrote:
> On 5/8/2014 17:20, Rainer Emrich wrote:
>> I try to bootstrap gcc-4.9.0 for cygwin 64-bit, but this fails in adalib.
>> AFAIS upstream are still some patches missing which are in the gcc-4.8.2-3 
>> source.
>>
>> Does anybody knows the status for these patches?
>>
> 
> I am working on them, albeit slowly, you can look at the current 4.8.x
> patches, some need rebasing.
> 
> 

CC'ed. I only plan to put 4.9.0 into experimental if I do actually fix
the patches. The actual release will probably come from 4.9.1 or later.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: w32api-headers-3.1.0-2

[JonY]

New release for both 32bit and 64bit Cygwin:

w32api-headers-3.1.0-2

This update contains some correction and updates for the GL headers.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.9.0-1 experimental (x86_64)

[JonY]

gcc-4.9.0-1 for 64-bit Cygwin is now uploaded as experimental, no
serious testing has been done yet, you may use it for not-so-important work.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: Default manifest

[JonY]

On 5/21/2014 21:19, Ken Brown wrote:
>>
>> For the default manifest to get going we also need the patcha new GCC
>> with Nick's patch from
>>
>>https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01378.html
>>
>> Is that easily backportable to GCC 4.8, or does 4.8 not support the
>> %if-exists functionality?
> 
> JonY, any chance we could get a release of GCC that includes this patch?
> 
> Ken
> 

Sure, I'll take a jab at it this weekend.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.3-1 (x86/x86_64)

[JonY]

gcc-4.8.3-1 is now uploaded for both 32-bit and 64-bit Cygwin. This
includes a patch to automatically link in the default manifest for
executable files.

Known issues:
Cygwin 64-bit gcc-4.8.3-1 debuginfo package is missing and was not
generated by cygport, I am still investigating this.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.3-1 (x86/x86_64)

[JonY]

On 5/29/2014 03:47, Chris J. Breisch wrote:
> Ken Brown wrote:
>> On 5/28/2014 1:13 PM, Chris J. Breisch wrote:
> 
> Yes, the behavior looks exactly like what you described there.
> 
> $ objdump -j .rsrc -s /usr/bin/g++.exe
> 
> /usr/bin/g++.exe: file format pei-x86-64
> 
> Contents of section .rsrc:
> objdump: Reading section failed
> 
> 

gcc.exe seems to work fine though, this could explain the broken debuginfo.

cgf: Should I remove 4.8.3-1 from x86_64 for now until it is fixed?




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.3-1 (x86/x86_64)

[JonY]

On 5/29/2014 06:20, JonY wrote:
> On 5/29/2014 03:47, Chris J. Breisch wrote:
>> Ken Brown wrote:
>>> On 5/28/2014 1:13 PM, Chris J. Breisch wrote:
>>
>> Yes, the behavior looks exactly like what you described there.
>>
>> $ objdump -j .rsrc -s /usr/bin/g++.exe
>>
>> /usr/bin/g++.exe: file format pei-x86-64
>>
>> Contents of section .rsrc:
>> objdump: Reading section failed
>>
>>
> 
> gcc.exe seems to work fine though, this could explain the broken debuginfo.
> 

64bit 4.8.3-1 has been removed. Please use 4.8.2-3 for now.





signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.3-1 (x86/x86_64)

[JonY]

On 5/29/2014 07:00, JonY wrote:
> 64bit 4.8.3-1 has been removed. Please use 4.8.2-3 for now.
> 

I just realized I just uploaded a fixed 4.8.3-1 with the same 4.8.3-1
version string. I will upload again as 4.8.3-2 soon.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: gcc-4.8.3-1 (x86/x86_64)

[JonY]

On 6/3/2014 03:35, Angelo Graziosi wrote:
> JonY  wrote:
>> I will upload again as 4.8.3-2 soon.
> 
> This evening setup.ini has
> 
> 4.8.2-3 in current
> 
> ==> 4.8.3-2 in prev <==
> 
> 
> Sure this is what you want?
> 

Oh,

Looks like I messed up, I was wondering where it went. I am having
problems connecting to sourceware to check.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.3-2 (x86_64)

[JonY]

gcc-4.8.3-2 is now uploaded for 64-bit Cygwin. It is a rebuild of -1,
now with the other frontend drivers working. Debug info is also included.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.





signature.asc
Description: OpenPGP digital signature

Re: Question on gcc install

[JonY]

On 6/18/2014 05:33, Arthur Schwarz wrote:
> Hi Larry;
> 
> I think I mislead you. Netbeans is quite comfortable with cygwin, and I
> believe demands it in a Windows environment. What Netbeans requires is the
> exact oath to use for gcc, g++, gfortran, the assembler, make file, gdb, and
> qmake (optional). The make file path and gdb are invariant. The other
> executables must be provided (except for the unadornded gcc, g++, gfortran,
> and as). 
> 

http://wiki.osdev.org/Target_Triplet

No, gdb happens to be invariant because you don't have cross gdb
installed. You cannot debug 32bit code with 64bit gdb on Windows.

> The issue of "what's going on" first came up because gcc -m32 did not work
> for any compiler. In talking with  Marc Glisse @ gcc.gnu.org, he had some
> questions on c++config.h. In finding the path to and looking at this file I
> became confused as to the directories available, their use and their
> association with the executables and gcc versions. Given the latest (16 Jun)
> release I am further confused.
> 

Cygwin gcc has never supported -m32.

> At the present time /bin/gcc.exe, etc., works. /bin/*mingw*.exe either
> compiles but does not link, or does not compile - which seems to be a header
> issue. gcc -m32 does not work which may be a gcc.gnu issue.
> 

Can you at least be specific about the errors? It is rather frustrating
reading your emails, being so vague about and all. Are you mixing Cygwin
and mingw code?

> If there is a resource document that I can look at to find the meaning of
> life, could you tell me where to find it? I have downloaded the gcc.gnu.org
> document set for vrs. 4.8.3, Is this sufficient?

My advice is, stop jumping to conclusions, and stop assuming facts about
how things are related, and fix your email client to reply to threads
properly instead of starting a new thread for every reply.




signature.asc
Description: OpenPGP digital signature

Re: Question on gcc install

[JonY]

On 6/18/2014 23:11, Arthur Schwarz wrote:
> I am including cygcheck.out as an attachment. 
> 
> Andrey Repin pointed out to me that my various e-mail responses are
> scattered all over the mailing list. I am very sorry for this and hope that
> at least this e-mail is put in the appropriate place so that proper tracking
> can be done. If you have not seen my prior posts then some of the history
> and flavor of comments in this post may be lost.
> 

Please don't add "--" to separate your text from others too, it is
treated as a signature in some clients.

> I don't think that there is an error in cygwin. I think that the number of
> executables, directories, etc. is by intent. What I am trying to do is to
> discover the intent and then, if necessary, report errors.
> 
> Here are a list of guesses:
>/bin
>   i686-pc-cygwin.*  Related toolchain for a compiler
>   i686-pc-mingw32.* i686/x86 indicates the compiler instruction set
>   i686-w64-mingw32.*pc/w64 = 32/64-bits the input architecture (?)
>   x86_64-pc-cygwin.*cygwin/mingw32 the compiler producer
>   x86_64-w64-mingw32.*
> 
> It is also possible (again I'm guessing) the prefix represents the output
> architecture rather than the compiler architecture. This would (perhaps)
> explain why the gcc -m32 option has been disabled. If the -m32 option is not
> disabled by intent then there is a compiler bug, and if it is disabled by
> intent then this indicates a departure from behavior for a direct port.
> 

None of the toolchains are multilib capable, so -m32/-m64 is not going
to work. See also http://wiki.osdev.org/Target_Triplet

> Each prefix has two related directories:
>/usr   used by the compiler
>   i686-pc-cygwin/
>   i686-pc-mingw32/
>   i686-w64-mingw32
>   x86_64-pc-cygwin
>   x86_64-w64-mingw32
> 
>/usr/lib/gcc  contains version specific data for user (& compiler?)
>   i686-pc-cygwin/vrs/
>   i686-pc-mingw32/vrs/
>   i686-w64-mingw32/vrs/
>   x86_64-pc-cygwin/vrs/
>   x86_64-w64-mingw32/vrs/
> 
> Prefixes with an appended version number in /bin are given as a visual
> indication of the version of the software associated with the prefix. For
> example, i686-pc-cygwin-gcc-4.8.2.exe indicates that the toolchain for
> i686-pc-cygwin is specific to gcc 4.8.2. I think that
> i686-pc-cygwin-gcc-4.8.2.exe is the same file as i686-pc-cygwin-gcc.exe.
> 

Yes.

> Supposing the following seems to have occurred with this release.
> 1: The use of appended version numbers in /bin has been abandoned.
> 2: The latest distribution (16 Jun) has an error in that x86_64-w64-mingw32
> does not have an associated file in /usr/. There is an associated file in
> /usr/lib/gcc however.
> 

What?

> What I would (ultimately) like to discover is resource material containing
> the exact expected configurations and the meanings for all the prefixes.

http://wiki.osdev.org/Target_Triplet

> What is what and what goes where. And I would like to have a resource rather
> than wasting bandwidth on the mailing list. To this I would add that the
> information in /usr/share/doc/gcc is not specific to the installation on
> cygwin, and also that /usr/share/gcc-vrs/ has a nested python script. What
> on Earth is the python script for?
> 

It is for gdb pretty-printing. Your questions are more appropriate on
gcc-help.




signature.asc
Description: OpenPGP digital signature

Re: Question on gcc install

[JonY]

On 6/20/2014 07:58, Arthur Schwarz wrote:
> Hi JonY;
> 
> I hope that this clarifies some of the thing yous mentioned (as well as
> others unmentioned).
> 
> None of the toolchains are multilib capable, so -m32/-m64 is not going
> to work. See also http://wiki.osdev.org/Target_Triplet
>"> info gcc -> Option Index" shows -m32 and -m64 as valid 
>Options Are there plans to change the info files so that 
>they better represent the distributed versions of the 
>compiler?
> 

Yes, they are valid options to gcc, but that does not mean gcc is able
to honor them. None of the builds are specifically set up for multilib.

> No, gdb happens to be invariant because you don't have cross gdb
> installed. You cannot debug 32bit code with 64bit gdb on Windows.
>Would it be possible to clarify that 64-bit compiler target
>Will only work on a compatible 64-bit gdb (same for 32-bit)
>and that in order to get gcc to generate code for 32-bit
>targets the setup-x86.exe must be used ant that in order to
>get 64-bit target code setup-x86_64.exe must be used?
> 
> 

No, use the cross compilers, host and target triplets are not tied to
each other. You can easily run a 32bit compiler that targets 64bt etc,
eg x86_64-w64-mingw32-gcc on 32bit Cygwin.

>> If there is a resource document that I can look at to find the meaning of
>> life, could you tell me where to find it? I have downloaded the 
>> gcc.gnu.org document set for vrs. 4.8.3, Is this sufficient?
> 
> My advice is, stop jumping to conclusions, 
>Could you please clarify what in the above sentence draws a 
>conclusion? Are you saying that if I have concluded that
>documentation exists that it does not?
> 

You jump to conclusion about "version" strings and "triplets", assume
differences where there are none.

> and stop assuming facts about how things are related, 
>Could you please clarify what in the above sentence supports your 
>statement? Are you saying that the gcc documentation for vrs. 4.8.3
>Is not related to the gcc port?
> 

Just start using ${prefix}-gcc for cross compiles, and "gcc" for native
compiles, likewise for other frontend drivers.

> 
>What on Earth is the python script for?
>   It is for gdb pretty-printing. Your questions are more 
>   appropriate on gcc-help.
>  Is there some reason a gdb script is located under
>  A gcc directory and not a gdb directory?
> 

Because libstdc++ internal structures are tied to gcc, not gdb.

> 
>Supposing the following seems to have occurred with this release.
>   1: The use of appended version numbers in /bin has been 
>  abandoned.

That is up to upstream gcc to decide, I don't control how the executable
end up as.

>   2: The latest distribution (16 Jun) has an error in that 
>  x86_64-w64-mingw32 does not have an associated file 
>  in /usr/. There is an associated file in /usr/lib/gcc 
>  however.
> 

It doesn't really matter where it goes, there is no meaning in it.

>   What?
>  In trying to understand your comment I assume that you
>  Are questioning items 1: and 2: above. 
>  1: the latest download, unlike previous downloads, is
>  Missing compiler files such as 
>  i686-pc-cygwin-gcc-4.8.2.exe.

Use "i686-pc-cygwin-gcc", so you don't have to mess around each and
every update.

>  2: In all cases except x86_64-w64-mingw32, there is
> a directory in /usr and /usr/lib/gcc with the
> same toolchain prefix as in /bin. Without being
> tendentious I assume that you understand the
> toolchain prefix as defined in 
> http://wiki.osdev.org/Target_Triplet. You have 
> requested that I make no assumptions, so I now
> assume that the omission is deliberate and 
> need no further investigation or action.
> 

That is right, because there is no hidden conspiracy theory behind it.

>From http://wiki.osdev.org/Target_Triplet the compiler names
>are:
>   machine-vendor-operatingsystem
> 
>For the cygwin distribution this translates to:
> i686-pc-cygwin
> ||  o- operating system
> |o- vendor
> o- target platform
> 
> x86_64-pc-cygwin
> |  |  o- operating system
> |  o- vendor
> o- target platform
> 
> i686-pc-mingw32/
> ||  o- operating system
> |o- vendor
> o- target platform
> 
> i686-w64-mingw32
> ||   o- operating system
> |o-

Re: Question on gcc install

[JonY]

On 6/20/2014 22:37, Arthur Schwarz wrote:
> 
>> At the present time /bin/gcc.exe, etc., works. /bin/*mingw*.exe either
>> compiles but does not link, or does not compile - which seems to be a
> header
>> issue. gcc -m32 does not work which may be a gcc.gnu issue.
>>
> 
> Can you at least be specific about the errors? It is rather frustrating
> reading your emails, being so vague about and all. Are you mixing Cygwin
> and mingw code?
> 
>Sorry. I was remiss.
> 
>Execution fails on all of the mingw compilers with the same error
>message. All compilations use the same command line options.
> 
>> i686-pc-mingw32-g++ -Wall -Wno-reorder -Wno-unused-value -DYYDEBUG=1 
>  -DDEBUG_IO   -c -g -MMD -MP -MF
> 
>> slip.exe
> 
> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
> error while loading shared libraries: libstdc++-6.dll: cannot open shared
> object file: No such file or directory
> 
> RUN FAILED (exit value 127, total time: 15ms)
> 

You are not supposed to run cross compiled executable files. This is not
even a linker error.

> After execution I ran the following find on /usr.
> 
>> find /usr/i686-pc-cygwin 
>/usr/i686-pc-mingw32 
>/usr/i686-w64-mingw32 
>/usr/x86_64-w64-mingw32 -iname 'libstdc++-6.dll'
> 
> i686-pc-mingw32/sys-root/mingw/bin/libstdc++-6.dll
> i686-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
> x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
> 
> /usr/i686-pc-cygwin apparently does not use this dll and the generated mingw
> executables can not find it. Can anything be done about this - I refrain
> from 'guessing', 'inferring', or 'assuming (causality)'.
> 
> 

Do not guess, there is nothing to infer from it, it is done on purpose.
You will need to copy these to where your executable programs are
running. Additionally, you mustn't mix DLLs from different toolchains,
so in this case, take the dll from i686-pc-mingw32.






signature.asc
Description: OpenPGP digital signature

Re: Question on gcc install

[JonY]

On 6/22/2014 00:43, Arthur Schwarz wrote:
>> /E/home/skidmarks/Projects/SLIP/slip/dist/Debug/mingw-Windows/slip.exe:
>> error while loading shared libraries: libstdc++-6.dll: cannot open 
>> shared object file: No such file or directory
>>
>> RUN FAILED (exit value 127, total time: 15ms)
>>
> 
> You are not supposed to run cross compiled executable files. This is not
> even a linker error.
> 
> I compiled my program with each of the mingw32 compilers.
> After each compilation I copied the libstdc++-6.dll into
> the directory containing the compiled executable and then
> ran the compiled code. After each execution I received the
> same error. Are you saying that the mingw32 compiled code
> is cross-compiled to a non-intel, non-windows and/or
> non-cygwin architecture and that is why the code doesn't
> execute? What are you supposed to do with mingw32 compiled
> code instead of executing it?
> 
> 

There you go again with all the implications, mingw32 code is cross
compiled from Cygwin's point of view, so don't run it under Cygwin. Run
it under cmd or something.

Was that too hard to understand?




signature.asc
Description: OpenPGP digital signature

Re: Question on gcc install

[JonY]

On 6/22/2014 12:24, René Berber wrote:
> On 6/21/2014 9:13 PM, JonY wrote:
> 
>> There you go again with all the implications, mingw32 code is cross
>> compiled from Cygwin's point of view, so don't run it under Cygwin. Run
>> it under cmd or something.
>>
>> Was that too hard to understand?
> 
> Yes, because its not true, the code runs fine under Cygwin (as long as
> the executable and its dependencies are in the PATH, or on the current
> working directory, and all of them have the executable attribute set,
> i.e. it follows Windows' rules) the same as any other Windows program
> runs under Cygwin.

Sure you can make it work by messing with PATH, but you'd run into other
issues like PATH translation from the command line etc. Do to simplify
it for the user, just don't do it if you don't know what you're doing.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: mingw64-*-gcc-4.8.3-1

[JonY]

This update includes:

Update:
mingw64-*-gcc-4.8.3-1

*** NOTES ***
gcc-4.8.x is built as is from FSF sources.

C++11 std::to_string is now supported. Caveat: C++11 mode implies C99
mode vsnprintf and vsnwprintf, any calls to these will be redirected to
__mingw_* variants, not to msvcrt. That means no more using "%I64d" in
C++11 mode, use "%lld" or inttypes.h macros instead.

Default manifest support is still not included yet and will be added in
the next release.

**

The cross compiler can produce Win32 and Win64 native binaries. As a
cross compiler, you may use --host=i686-w64-mingw32 or
--host=x86_64-w64-mingw32 for autotools based source packages to build
for Windows.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.






signature.asc
Description: OpenPGP digital signature

Re: cygwin64 problems after update: gcc 4.8.3-2, cygcheck -p

[JonY]

On 7/6/2014 04:15, Lakhsa wrote:
> G'Day,
> 
> after having updated my cygwin64 installation (Win7-64) for OpenSSL
> development I have encountered 2 problems:
> 
>   * compiling for 32-bit with '-m32 -i686' now fails with internal
> compiler error: in extract_insn, at recog.c:2154
>   * cygcheck -p [any_binary] produces a seg fault
> 
> Both used to work until last update of the cygwin64-only setup end of
> June 2014 from FTP server at Uni Erlangen.

Really? cygwin gcc has never been built with multilib support, I don't
know how it is possible that "it used to work".





signature.asc
Description: OpenPGP digital signature

Re: cygwin64 problems after update: gcc 4.8.3-2, cygcheck -p

[JonY]

On 7/6/2014 19:04, Lakhsa wrote:
> After some extended research and trials with a fresh OpenSSL master
> clone openssl32_trial this seems to be a problem of the cygwin ports of GCC.
> I've added some information about this - maybe one of the developers
> listening in on the OpenSSL project could have a closer look.
> 

cygwin gcc has never been built with multilib support, I don't
know how it is possible that "it used to work".




signature.asc
Description: OpenPGP digital signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

On 7/15/2014 21:08, Corinna Vinschen wrote:
>>
>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> 
> JonY, do you have a chance to have a look into this issue?
> 

Sorry, I have been busy these few weeks, but I am well aware that there
is a problem with one of the libgcc changes, but has yet to investigate it.

I believe Jon Turney has looked into it somewhat.




signature.asc
Description: OpenPGP digital signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

On 7/16/2014 15:02, Corinna Vinschen wrote:
> Hi JonY,
> 
> On Jul 15 16:39, Corinna Vinschen wrote:
>> On Jul 15 21:55, JonY wrote:
>>> On 7/15/2014 21:08, Corinna Vinschen wrote:
>>>>>
>>>>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
>>>>
>>>> JonY, do you have a chance to have a look into this issue?
>>>>
>>>
>>> Sorry, I have been busy these few weeks, but I am well aware that there
>>> is a problem with one of the libgcc changes, but has yet to investigate it.
>>>
>>> I believe Jon Turney has looked into it somewhat.
>>
>> Sounds good.  Thanks in advance.
> 
> Yesterday I asked my collegues to take a stab at the issue and one of
> them, DJ Delorie, came up with a libgcc patch already.  It hasn't been
> sent upstream yet.  Can we give it a try, perhaps by creating a new
> libgcc DLL, please?
> 

Thanks, I'll get to it this weekend, should I make the new gcc an
experimental version? Or is just the libgcc binary required?





signature.asc
Description: OpenPGP digital signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

On 7/18/2014 02:24, Corinna Vinschen wrote:
>>> Is this essentially the same problem as described here?
>>>
>>>  
>>
>> No, I think it is an unforeseen consequence of the patch [3] to fix that bug
>> [4], which I believe is present in 4.8.3-1, introducing a new problem when
>> an executable which doesn't depend on libgcc dlopen()s a dll which does.
>>
>> [1] https://cygwin.com/ml/cygwin/2014-07/msg00083.html
>> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752
>> [3] https://sourceware.org/ml/cygwin/2013-07/msg00528.html
>> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982
> 
> I asked DJ to take another look, but I guess ultimately we need the
> attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
> unavailable right now, unfortunately.
> 

Looks like I haven't had much luck at poking the code to work over the
weekends.





signature.asc
Description: OpenPGP digital signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

On 7/24/2014 21:45, Corinna Vinschen wrote:
> 
> JonY, any chance we could get a gcc package with the new crtbegin.o
> soon?

Yes, I just uploaded gcc-4.8.3-2, I'll announce once it hits the mirrors.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.3-2 (x86)

[JonY]

gcc-4.8.3-2 is now uploaded for 32-bit Cygwin. This release hopefully
fixes the dw2 unwind problem, thanks to DJ for the crtbegin patch.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.





signature.asc
Description: OpenPGP digital signature

Re: New Git v2.0.4 build to test

[JonY]

On 8/6/2014 22:18, Corinna Vinschen wrote:
>> `git fetch` occasionally hangs in the test suites in 64-bit)
>> and there are probably some problems I haven't identified yet.
>>
>> I'm currently in the process of working through the Git test suite
>> output to identify missing features, since it's the best way I've found
>> to identify features the Git compile process has quietly skipped since a
>> required library wasn't installed.
> 
> If the git build system uses autotools, you might have an easier time by
> scanning the config.log file created during the configure call.
> 

It does, I have been using git 2.x since the last 2 months. And yes,
PCRE is an optional requirement.





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: binutils-2.24.51-5 (x86/x86_64)

[JonY]

binutils-2.24.51-5 is now uploaded for both 32-bit and 64-bit Cygwin.
This includes a patch to exclude __dso_handle from being externally
visible in DLLs for the upcoming Cygwin __cxa_atexit support.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: gcc-4.8.3-3 (x86/x86_64)

[JonY]

gcc-4.8.3-3 has been uploaded for 32bit and 64bit Cygwin. This rebuild
now uses __cxa_atexit for better C++ standards compliance.

Note that any C++ code built with this version WILL NOT RUN on earlier
versions of Cygwin (1.7.32-1).

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.






signature.asc
Description: OpenPGP digital signature

Re: ld segfaults with -flto after upgrading to gcc 4.8.3-3 (64-bit)

[JonY]

On 8/22/2014 08:20, Christoph H. Hochstaetter wrote:
> Hi,
> 
> I just upgraded gcc from 4.8.3-2 to 4.8.3-3. ld segfaults if gcc (and thus
> ld) is used with link time optimization (-flto).

Looks like it is crashing at exit(), not sure how that happens, Corinna,
help? :)





signature.asc
Description: OpenPGP digital signature

Re: [1.5] question about python/ctypes/dlopen

[JonY]

On 12/4/2009 22:53, kiorky wrote:

Hello, i'm trying to use python ctypes which use under the hood dlopen.
I have a strange permission denied running this following code, if someone have
clues ...

Base code

$ cat test_ctypes.py
from ctypes import  CDLL
CDLL('libgeos_c.dll.a')



Hi,

have you tried loading "cyggeos_c-1.dll" instead of the import library?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [1.5] question about python/ctypes/dlopen

[JonY]

On 12/4/2009 23:33, kiorky wrote:



JonY a écrit :

On 12/4/2009 22:53, kiorky wrote:
Hi,

have you tried loading "cyggeos_c-1.dll" instead of the import library?


Yep, just look at the second part of the first mail
It results in "bad address" instead of "permission denied"



Hi,

Sorry, I was jumping to conclusions, I'm not a python guru either. I 
tried with:


>>> import ctypes
>>> ctypes.CDLL("/bin/cygwin1.dll");


It seems to work. I suggest loading other dlls for testing.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Appropriate expectation on the degree of cygwin and MS interoperability

[JonY]

On 1/1/2010 20:06, neil.mowb...@calgacus.com wrote:

Folks,

A bit of a vague question but any greater clarity concerning the appropriate
level of interoperability between Cygwin and MS would be appreciated.

I have my Windows 6 and 7 platforms configured to build software using
different toolchains, the most common being (1) Visual Studio 10 and (2)
Cygwin with gcc-4.

When using the Visual Studio toolchain I will prefer a cygwin tool over a
MS tool, so for example, I always use bash and gnu make and never use the
cmd shell/power shell or nmake.  Taking this further, I will try to use
nm over dumpbin and ar over lib.

For the most part the cygwin tools interoperate with MS artifacts but
it does break down, especially, with 64bit artifacts.  For example, nm
can work with 32bit object files created by MS cl.exe but it cannot
work with 64bit MS object files (unrecognised file format).

The question is: how far should I expect the interoperability to go?
For example, is the fact that nm cannot handle 64bit MS object files
a (1) defeat in cygwin/nm or (2) I should be grateful that it works
with 32bit files and otherwise lower my expectation?

I suppose at its core the question is about the intent of cygwin.  Is
it (1) to provide unix like capabilities to a MS platform (in which case
one would expect/demand a high degree of interoperability), or
(2) to provide a unix like island inside a MS platform?

The problem with (2) is one cannot really stay isolated from the
host MS environment.

My previous question of how/if one can use cyginw *.h *.dll *.a
artifacts in a MS compiled program is essentaily the same theme
although I have lower expectations that it is possible.

Any pointers?


Hi,

for nm to recognize 64bit objects, you need to rebuild binutils to 
recognize 64bit objects. Use 
--enable-target=i686-pc-cygwin,x86_64-w64-mingw32 with binutils 
configure. Beware that MSVC now uses the "short" library format instead 
of the older "long" library format used by the GNU toolchain.


See  for toolchains targeting win64.

IMHO Cygwin is more of an island, you're supposed to use Cygwin tools 
only under Cygwin. Others might have different opinions.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Appropriate expectation on the degree of cygwin and MS interoperability

[JonY]

On 1/1/2010 20:37, JonY wrote:

On 1/1/2010 20:06, neil.mowb...@calgacus.com wrote:

Folks,

A bit of a vague question but any greater clarity concerning the
appropriate
level of interoperability between Cygwin and MS would be appreciated.

I have my Windows 6 and 7 platforms configured to build software using
different toolchains, the most common being (1) Visual Studio 10 and (2)
Cygwin with gcc-4.

When using the Visual Studio toolchain I will prefer a cygwin tool over a
MS tool, so for example, I always use bash and gnu make and never use the
cmd shell/power shell or nmake. Taking this further, I will try to use
nm over dumpbin and ar over lib.

For the most part the cygwin tools interoperate with MS artifacts but
it does break down, especially, with 64bit artifacts. For example, nm
can work with 32bit object files created by MS cl.exe but it cannot
work with 64bit MS object files (unrecognised file format).

The question is: how far should I expect the interoperability to go?
For example, is the fact that nm cannot handle 64bit MS object files
a (1) defeat in cygwin/nm or (2) I should be grateful that it works
with 32bit files and otherwise lower my expectation?

I suppose at its core the question is about the intent of cygwin. Is
it (1) to provide unix like capabilities to a MS platform (in which case
one would expect/demand a high degree of interoperability), or
(2) to provide a unix like island inside a MS platform?

The problem with (2) is one cannot really stay isolated from the
host MS environment.

My previous question of how/if one can use cyginw *.h *.dll *.a
artifacts in a MS compiled program is essentaily the same theme
although I have lower expectations that it is possible.

Any pointers?


Hi,

for nm to recognize 64bit objects, you need to rebuild binutils to
recognize 64bit objects. Use
--enable-target=i686-pc-cygwin,x86_64-w64-mingw32 with binutils
configure. Beware that MSVC now uses the "short" library format instead
of the older "long" library format used by the GNU toolchain.



Correction:
I mean ".obj" object file format, not the ".lib" library format. The
latter stays mostly the same.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: old install instructions? -mnomingw being removed?

[JonY]

On 1/2/2010 07:52, Ken Tilton wrote:

Sorry, I am a complete noob to all this make/install/gcc stuff, I am just trying
to make a fresh build of a DLL I have used for years to see if it resolves a
problem.

I installed cygwin 1.7.1 today on a windows 7 laptop.

The directions for my library are great:

"VER=8.4.12
SRCDIR=`pwd`

cd $SRCDIR/tcl$VER/win
env 'CC=gcc -mno-cygwin' ./configure --enable-threads
make libtclstub84.a

cd $SRCDIR/tk$VER/win
env 'CC=gcc -mno-cygwin' ./configure --enable-threads
make libtkstub84.a

cd $SRCDIR/Togl
env 'CC=gcc -mno-cygwin' ./configure --with-tcl=../tcl$VER/win --with-
tk=../tk$VER/win

make"

That's from doc for the lib which is Togl, an OpenGL add-on widget to Tcl/Tk.
Unfortunately the mailing list does not seem active, because:

The first env command responds "C compiler cannot create executables" and refers
me to the config.log. That has a few lines showing the -mno-cygwin flag has been
removed and telling me to use a mingw-targeted cross-compiler.

Not sure if those are warnings or that is why later what looks to be a hello-
world-like little C compile reports failure leading next to the "cannot create
exes" message.

Googling did turn up a long-ago discussion mentioning deprecating no-mingw (and
to my relief that this is not something poor know-nothings like me should
encounter) but the obvious solution ("a mingw-targeted cross-compiler") did not
work out two ways:

1. Just googling that did not cause anything to jump out at me.
2. I am wondering if this is a cross-compiler situaton, since I am on Windows
trying to build a windows DLL.

Any clues greatly appreciated!

kt



Hi,

The -mno-cygwin option has been removed from gcc4.

If you need it, install the gcc-mingw package via the Cygwin setup, and
use CC="gcc-3 -mno-cygwin" instead. It is an older version of GCC, but
it will get you somewhere.

Yes, it is a cross-compile situation. MinGW and Cygwin are considered
different hosts even if both are running on Windows. Cygwin programs
use cygwin1.dll while MinGW programs use msvcrt.dll.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [1.7] Updated: cygport-0.9.80-1

[JonY]

On 1/7/2010 16:42, Yaakov (Cygwin/X) wrote:

The following package has been updated for Cygwin 1.7:

*** cygport: 0.9.80-1



Hi,

The Cygwin setup lists 0.9.9-1 as latest, 0.9.80-1 as another available 
version, so any idea whats wrong?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [1.7] Updated: cygport-0.9.80-1

[JonY]

On 1/8/2010 03:05, Yaakov (Cygwin/X) wrote:

On 07/01/2010 10:05, JonY wrote:

The Cygwin setup lists 0.9.9-1 as latest, 0.9.80-1 as another available
version, so any idea whats wrong?


I checked setup.ini, and it shows 0.9.80-1 as latest and 0.9.9-1 as
previous.


Yaakov



Hi,

Strangely, I had to manually select 0.9.80-1 over the default 0.9.9-1. 
Anyway, 0.9.80-1 installed without issues once I selected it.


Thanks for updating it.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: lzip-1.9-1

[JonY]

Version 1.9-1 of "lzip" has been uploaded.

lzip is a lossless data compressor based on the LZMA algorithm with a
user interface similar to gzip or bzip2. It supports recovery from
damaged archives.

Homepage: 

This is a new upstream release. Changes include:

2010-01-17  Antonio Diaz Diaz  

* Version 1.9 released.
* main.cc (main): return at least 1 if closing stdout fails.
* Makefile.in: Added "--name" option to help2man invocation.
* testsuite/check.sh: Use "test1" instead of "COPYING" for testing.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: ./configure on cygwin in window platform

[JonY]

On 2/1/2010 21:49, J J wrote:

Please help me out. I spent for three days but I still could install gcc in 
window on cygwin.

Problem is I could not install gcc file, 
(mingw-w64-trunk-snapshot-20091222.tar.bz2), on cygwin in window platform.

I would like to unpack and intall gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) on 
cygwin on window platform. I follow instruction posted on 
http://cygwin.wikia.com/wiki/How_to_install_GCC_4.3.0. The problem I have found out is I 
could not process the configure step as below. The result shows "No such file or 
directory"

Steps:
$ mkdir build
$ cd build
$ ../gcc-*/configure --enable-languages=c,c++
$ make
$ make install

May it be because of (1) setting srcdir or objdir non-correctly or (2) else ?

What I have done are:
1. Download gcc file and load it into /usr/build. Build subfolder is created by 
me. -->  ( equal to $ mkdir build  and  $ cd build)
2. Unpack gcc tar.bz2 file (mingw-w64-trunk-snapshot-20091222.tar.bz2) on that 
location. -->  It generates trunk subfolder that contains some subfolder too.
3. $mkdir build  and $cd build -->  current location is urs/build
4. $ ../trunk/configure --enable-languages=c,c++  -->  It does not work. Error = "No 
such file or directory"

Comparing to what you recommend on http://gcc.gnu.org/install/configure.html ,

To configure GCC:
% mkdir objdir
% cd objdir
% srcdir/configure [options] [target]

You mentions that  objdir can not be a subdirectory of srcdir.  This is why I 
tried one more time with the different folder and the same level under usr 
folder. What I did are:

1. Download gcc (mingw-w64-trunk-snapshot-20091222.tar.bz2) for window platform 
again into usr/tmp
2. Unpack it in the usr/tmp/. The path result are approximately
 usr/tmp/trunk/mingw..1*
 usr/tmp/trunk/mingw..2*
 usr/tmp/trunk/mingw..3*
 usr/tmp/trunk/mingw..4*

3. $cd build -->  under usr folder -->  current location is usr/build -->  
build is already created by me on the previous work.
4  command to configure ->  $../mingw-w64-trunk-snapshot-20091222.tar.bz2/configure 
--enable-language=c,c++  -->  Show error msg = "No such file or directory"
5. Try $ ../trunk/mingw-w64-trunk-snapshot-20091222.tar.bz2/configure 
--enable-language=c,c++  -->  Show error msg = "No such file or directory".


Please help me out. I don't why I could not and thank you very much,
Jasmine
Ps. I am pretty much new with cygwin and this is my first time.


Hi,

you've unpacked it to usr/tmp/trunk..., in usr/build, use ../trunk
/.../mingw... instead.

You have also forgot to set --target, please read the mingw-w64 build
instructions more carefully.

I suggest you read .
It would help a new user like you to make sense of the CLI environment.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: lzip-1.10-1

[JonY]

Version 1.10-1 of "lzip" has been uploaded.

lzip is a lossless data compressor based on the LZMA algorithm with a
user interface similar to gzip or bzip2. It supports recovery from
damaged archives.

Homepage: 

This is a new upstream release. Changes include:

2010-04-05  Antonio Diaz Diaz  

* Version 1.10 released.
* decoder.h: Input_buffer integrated in Range_decoder.
* main.cc: File specified with option "-o" is now created with
  mode 0666 if umask allows it, deleted if interrupted by user.
* main.cc: New constant "o_binary".
* main.cc: Dictionary size for options -2, -3, -4 and -8 has
  been changed to improve linearity of compressed sizes.
* lzip.h: Fixed warnings produced by over-optimization (-O3).
* Makefile.in: Added quotes to directory names.


  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] New package: lzip-1.8-1

[JonY]

Version 1.8-1 of "lzip" has been uploaded.

lzip is a lossless data compressor based on the LZMA algorithm with a 
user interface similar to gzip or bzip2. It supports recovery from 
damaged archives.


Homepage: 

Changes from upstream:

- version 1.8-1 -
   * configure: Set EXEEXT for Cygwin.
   * Makefile.in: Make sure installed programs have .exe extension

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look 
at the "List-Unsubscribe: " tag in the email header of this message. 
Send email to the address specified there. It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available 
starting at this URL.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: New package: lzip-1.8-1

[JonY]

On 11/17/2009 23:18, Buchbinder, Barry (NIH/NIAID) [E] wrote:

JonY sent the following at Wednesday, November 11, 2009 6:36 AM


Version 1.8-1 of "lzip" has been uploaded.

lzip is a lossless data compressor based on the LZMA algorithm with
a user interface similar to gzip or bzip2. It supports recovery from
damaged archives.

Homepage:<http://www.nongnu.org/lzip/lzip.html>


Apparently this was up-loaded only to /release-2/ (1.7).  The
announcement says nothing about this being a 1.7-only package.  If it
was meant to also be a 1.5 package, please upload it to /release/.

Thanks to all.

- Barry


Sorry, I have failed to mention it as being a 1.7 only package for now. 
I do not currently have Cygwin 1.5 installed.


I will try to get a Cygwin 1.5 build in a few days.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: New package: lzip-1.8-1

[JonY]

On 11/19/2009 21:26, Buchbinder, Barry (NIH/NIAID) [E] wrote:

JonY sent the following at Thursday, November 19, 2009 1:18 AM



JonY sent the following at Wednesday, November 11, 2009 6:36 AM


Version 1.8-1 of "lzip" has been uploaded.

lzip is a lossless data compressor based on the LZMA algorithm with a
user interface similar to gzip or bzip2. It supports recovery from
damaged archives.

Homepage:<http://www.nongnu.org/lzip/lzip.html>



On 11/17/2009 23:18, Buchbinder, Barry (NIH/NIAID) [E] wrote:


Apparently this was up-loaded only to /release-2/ (1.7).  The
announcement says nothing about this being a 1.7-only package.  If it
was meant to also be a 1.5 package, please upload it to /release/.


Sorry, I have failed to mention it as being a 1.7 only package for now.
I do not currently have Cygwin 1.5 installed.
I will try to get a Cygwin 1.5 build in a few days.


Jon,

Please don't feel that you have to prepare a 1.5 package for me.  I just
wanted to be sure that a mistake hadn't been made.

I've never used lzip and just wanted to try it.  I'm switching to 1.7
when it will be officially released and can try lzip then.

- Barry
   Disclaimer: Statements made herein are not made on behalf of NIAID.



Hi,
IMO, Cygwin 1.5 is nearly deprecated. For completeness, lzip for Cygwin 
1.5 should be up on the mirrors by now.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[1.7] .exe append weirdness

[JonY]

Hi,

I'm using a win64 target cross compiler under Cygwin. I noticed all the 
stripped dlls will eventually end with ".exe".


I am on 32bit Windows XP sp3, Cygwin 1.7.0-64. (Upgrading to -65 causes 
"system shared memory version mismatch detected" for all Cygwin apps, 
its another issue altogether.


This does not happen to native win32 dlls produced with -m32 or with 
Cygwin dlls.


Here's an example session:


u...@user ~
$ echo "int f(void){return 5;}"|x86_64-w64-mingw32-gcc -xc - -shared -o 1.dll

u...@user ~
$ ls
1.dll*

u...@user ~
$ x86_64-w64-mingw32-strip -vs 1.dll
copy from `1.dll' [pei-x86-64] to `stEvbXqW' [pei-x86-64]

u...@user ~
$ ls
1.dll.exe*



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mismatch [1.5] [1.7]: lzip-1.8-1

[JonY]

On 11/22/2009 11:17, Christopher Faylor wrote:

On Sat, Nov 21, 2009 at 10:09:38PM +, Dave Korn wrote:

Fergus Daly wrote:


In setup.ini timestamp 1258779760
install: release/lzip/lzip-1.8-1.tar.bz2 101110 bca3c8d04c4fc90d576b264aaa0a08b7
source: release/lzip/lzip-1.8-1-src.tar.bz2 68215 
305bd012b1137907eb41972111d36def
In setup-2.ini timestamp 1258809078
install: release/lzip/lzip-1.8-1.tar.bz2 66427 a9edda6f8c04cc644897f8adc5323ce3
source: release/lzip/lzip-1.8-1-src.tar.bz2 68198 
12dbe475f1b28bede603bdfac091331b
Same version number, different versions?


  Well, yes; one's for 1.5 and the other is for 1.7.


But one really should be -1 and the other -2 for just this reason.



Ok, should I release a -2 at the same time for both 1.5 and 1.7, or a -2 
just for 1.5 should do?


I didn't have Cygwin 1.5 installed when I packaged for 1.7. lzip for 1.5 
was released after OP asked about it, some time later after lzip for 1.7 
was uploaded.


Sorry about the mess.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Mismatch [1.5] [1.7]: lzip-1.8-1

[JonY]

On 11/22/2009 12:17, Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to JonY on 11/21/2009 9:12 PM:


But one really should be -1 and the other -2 for just this reason.



Ok, should I release a -2 at the same time for both 1.5 and 1.7, or a -2
just for 1.5 should do?


Release a single -2 for just one of the two versions (your choice of
whether it is for 1.5 or for 1.7); but do NOT do a -2 for both 1.5 and
1.7, or we are right back to the complaint.  In future builds, if you want
to continue supporting both 1.5 and 1.7, be sure that the numbering for
1.5 is different than the numbering for 1.7.  That way, when someone asks
about -1, you can unambiguously determine for which version of cygwin they
are asking about.



Hi,

Good point, I haven't thought of that. I've sent -2 for 1.7 to cygwin-apps.

Perhaps somebody should add a hint to packaging guide at 
<http://cygwin.com/setup.html> about maintaining packages for 2 or more 
versions of Cygwin.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2

[JonY]

Version 1.8-2 of "lzip" has been uploaded for Cygwin 1.7.

lzip is a lossless data compressor based on the LZMA algorithm with a
user interface similar to gzip or bzip2. It supports recovery from
damaged archives.

Homepage: 

This update fixes a packaging conflict with lzip-1.8-1 on Cygwin 1.5.
There are no actual changes, just a release version bump. Sorry for the
mess.

Changes:

- version 1.8-2 -
* Fix up packaging so Cygwin 1.5 and 1.7 builds do not conflict.

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2

[JonY]

On 11/23/2009 17:25, Corinna Vinschen wrote:

On Nov 23 07:28, Fergus wrote:

Sorry, still something not quite right.
setup-2.ini timestamp 1258914641
shows

@ lzip
sdesc: "Lossless data compressor based on the LZMA algorithm."
ldesc: "lossless data compressor based on the LZMA algorithm, with very
  safe integrity checking and a user interface similar to the one of
  gzip or bzip2."
category: Archive
requires: cygwin libgcc1 libstdc++6

but no mention of

version:
install:
source:


Which makes sort of sense, given that no lzip tar archive was in the
release-2/lzip subdirectory.  I fixed that on cygwin.com, so it should
be propagated to the mirrors soon.



Hi,

I thought that setup.ini generation was smart enough to figure it out, 
I'll be sure to have those in the .hint file next time.


btw, lzip-1.8-2.tar.bz2 was missing?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [1.7] Updated: lzip 1.8-2

[JonY]

On 11/23/2009 19:05, Corinna Vinschen wrote:

On Nov 23 18:28, JonY wrote:

On 11/23/2009 17:25, Corinna Vinschen wrote:

On Nov 23 07:28, Fergus wrote:

but no mention of

version:
install:
source:


Which makes sort of sense, given that no lzip tar archive was in the
release-2/lzip subdirectory.  I fixed that on cygwin.com, so it should
be propagated to the mirrors soon.


I thought that setup.ini generation was smart enough to figure it
out, I'll be sure to have those in the .hint file next time.


No!  Don't do that, these are autogenerated values which are NOT
supposed to be in the setup.hint file.


btw, lzip-1.8-2.tar.bz2 was missing?


Yes, as well as the -src.tar.bz2 file.  That was the sole reason for
the missing setup-2.ini entries.



I thought cgf uploaded the packages. Upload went missing?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: mingw64-{headers,runtime,winpthreads} w32api-* 3.2.0-1

[JonY]

Now released for both 32bit and 64bit Cygwin:

mingw64-*-headers-3.2.0-1
mingw64-*-runtime-3.2.0-1
mingw64-*-winpthreads-3.2.0-1
w32api-headers-3.2.0-1
w32api-runtime-3.2.0-1

Notable changes:
* Add aliases for non-dllimport _get_invalid_parameter_handler and
_set_invalid_parameter_handler

* Fix D2DERR_INSUFFICIENT_BUFFER definition

* Fix off by one ipsectypes.h: Begin IPSEC_CIPHER_TYPE enumeration at 1

* Add missing @4 decoration for TryAcquireSRWLockExclusive, and
TryAcquireSRWLockExclusive

And many more fixes.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list,
look at the "List-Unsubscribe: " tag in the email header of this
message. Send email to the address specified there. It will be in the
format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that
is available starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mingw64-{headers,runtime,winpthreads} w32api-* 3.2.0-1

[JonY]

binsjTA3y_sIu.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message

Re: [ANNOUNCEMENT] Updated: mingw64-{headers,runtime,winpthreads} w32api-* 3.2.0-1

[JonY]

On 9/17/2014 17:02, Dominik Straßer wrote:
> Hi,
> these files did not yet appear on any mirrors.
> Did anything go wrong here ?
> 
> Best regards
> 
> Dominik

Sorry about the earlier mail, I meant to say kernel.org looks alright.





signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: mingw64-{headers,runtime,winpthreads} w32api-* 3.2.0-1

[JonY]

On 9/17/2014 17:55, Dominik Straßer wrote:
> Really ?
> I just checked mirrors.kernel.org in the cygwin installer and it gives
> me only 3.1.0-1 for e.g. mingw64-x86_64-runtime.
> 

Yes, looks like the x86_64 headers and runtime are missing, I will
upload them shortly.




signature.asc
Description: OpenPGP digital signature

Re: ld crashes with segmentation fault when linking with libmpir.a

[JonY]

On 9/18/2014 03:20, Daniel R. Grayson wrote:
> ld crashes with segmentation fault when linking with libmpir.a
> 
> To reproduce:
> 
> wget http://mpir.org/mpir-2.6.0.tar.bz2
> tar xjf mpir-2.6.0.tar.bz2
> cd mpir-2.6.0
> ./configure --build=x86_64-pc-cygwin
> make
> ld -u __gmpn_gcdext .libs/libmpir.a
> 

What are you trying to accomplish? I suspect this will not work on Windows.





signature.asc
Description: OpenPGP digital signature

Re: ld crashes with segmentation fault when linking with libmpir.a

[JonY]

binxs4f60pc5A.bin
Description: PGP/MIME version identification


encrypted.asc
Description: OpenPGP encrypted message