Re: 64 bit editrights package & csih

2013-04-08 Thread Charles Wilson

On 4/7/2013 12:21 AM, Charles Wilson wrote:

On 4/5/2013 10:15 AM, Corinna Vinschen wrote:

Chuck, editrights was the last dependency missing for csih.  Would you
mind to build a new package?  I was going to just copy it over from the
32 bit release area, but then it occured to me that it isn't just a
script,
but contains binaries as well...


I planned to get my 64bit-package-building-environment up and functional
Sunday pm, so I'll work on it then, along with the pointer Yaakov sent me.


32bit csih updated to 0.9.7-1. 64bit version uploaded to 64bit release area.

--
Chuck




Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1

2013-04-08 Thread JonY
On 4/9/2013 03:58, Charles Wilson wrote:

> 
> Yes. I'm not sure how that should be handled. If you want to "force" the
> switch, for that particular toolchain, then the cygwin package of the
> mingw-w64-headers for that toolchain should probably stop shipping those
> files, so that the (new) winpthreads package for that toolchain can
> start shipping them.
> 
> If you DON'T want to force the switch, then...? Use the alternatives
> framework for those particular headers?
> 


Good point, I'll simply remove the headers on my next header/CRT refresh
if I ship winpthreads. It's not something that can be switched easily as
it changes the underlying libgomp ABI, requiring GCC to be recompiled to
work with pthreads-win32.






signature.asc
Description: OpenPGP digital signature


64bit coreutils libgmp dependency

2013-04-08 Thread Ronald Blaschke

@ coreutils
...
requires: bash libattr1 libgmp3 libiconv2 libintl8 tzcode
...

I think this should be libgmp10, not libgmp3.  I noticed this because 
expr reported an error during a fresh install, and expr worked only 
after I installed libgmp10.


Ron


Re: 64bit: segfault : recv return type ?

2013-04-08 Thread marco atzeri

On 4/8/2013 12:04 PM, Corinna Vinschen wrote:


You're oh so right.  Thanks for tracking this down.  I'll fix that asap.


Should be fixed in CVS.  I'll create a new 64 bit Cygwin DLL later today.


Corinna



it works fine,

thanks
Marco



Re: 64bit cygport

2013-04-08 Thread Achim Gratz
Charles Wilson writes:
> On 4/7/2013 7:11 AM, Achim Gratz wrote:
>>
>> I've just set up a Cygwin64 system.  It seems I can run a 32bit Cygwin
>> in parallel without disturbing anything, is that right?
>
> FYI, unless I've misinterpreted, I think you need to use git master
> cygport to build "natively" in cygwin64.  If you're cross-building
> from cygwin32 to create cygwin64 packages, then you need to do
>
>cygport --64 ...blahblah...

Thanks, I've not tried any cross-compilation yet because I didn't
install the 64bit cross compilation toolchain in Cygwin32.  I'd
generally be more interested in the reverse direction, but it seems that
installing (and even running) both Cygwin flavors in parallel produces
the least headaches for me at the moment.

I've updated the cygport that came with setup64 to the Git version and,
more importantly, added my own patches on top of that so my workflow
actually works again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


Re: 64bit cygport

2013-04-08 Thread Charles Wilson

On 4/7/2013 7:11 AM, Achim Gratz wrote:


I've just set up a Cygwin64 system.  It seems I can run a 32bit Cygwin
in parallel without disturbing anything, is that right?


FYI, unless I've misinterpreted, I think you need to use git master 
cygport to build "natively" in cygwin64.  If you're cross-building from 
cygwin32 to create cygwin64 packages, then you need to do


   cygport --64 ...blahblah...

--
Chuck




Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1

2013-04-08 Thread Charles Wilson

On 4/7/2013 5:47 AM, JonY wrote:

For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the
32bit cygwin hits release, I will push it there too.

There are some files in the package that replaces


e.g. "conflict with"


some of the
mingw-w64-headers CRT headers, this is done on purpose. will
cygcheck/setup have any issues?


Yes. I'm not sure how that should be handled. If you want to "force" the 
switch, for that particular toolchain, then the cygwin package of the 
mingw-w64-headers for that toolchain should probably stop shipping those 
files, so that the (new) winpthreads package for that toolchain can 
start shipping them.


If you DON'T want to force the switch, then...? Use the alternatives 
framework for those particular headers?


--
Chuck



Re: Maintainers please weigh in on 64-bit Cygwin

2013-04-08 Thread Gernot Hillier

Hi there!

Am 17.03.2013 17:45, schrieb Christopher Faylor:

I'd like to have a feel for how the 64-bit version of Cygwin will
impact package maintainers.

So, I'd appreciate some discussion about this.

1) Do you have a 64-bit version of Windows available?


Yes


3) Are you willing to download the current 64-bit Cygwin and start porting
your stuff, knowing that there are still bugs?
4) Or, would you rather wait for 64-bit to be completely stable before
attempting anything?


Well, somewhere in between. As I only maintain tftpd which neither has a 
broad user base nor frequent upstream updates, I only look into Cygwin 
packaging every now and then.


So I'd love to see some "Howto get your package built on 64-bit" 
instruction. If things are shomehow shaky and unstable, that's no 
problem, I can happily try and report - but likely I won't have time to 
dig deeper or provide patches for other packages.



5) Does the existence of two different architectures make you think that
it is time for you to stop offering the package?


No.


6) Would you be willing to have another person doing the 64-bit port for
you?


As I don't expect too much overhead here: no.


7) Are you ok with a 64-bit alpha release being made available which contains
your packages built by someone else?


Don't think this makes sense for tftpd.

--
Gernot
Siemens CT RTC ITP SDP-DE, Corporate Competence Center Embedded Linux



Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1

2013-04-08 Thread Corinna Vinschen
On Apr  8 18:14, JonY wrote:
> On 4/8/2013 15:57, Corinna Vinschen wrote:
> > On Apr  7 17:47, JonY wrote:
> >> winpthreads is a pthreads implementation from mingw-w64. The ABI is
> >> incompatible with pthreads-win32. One of the major differences is that
> >> winpthreads uses scalar handles, so it is a bit more compatible to other
> >> packages that assume int type handles.
> >>
> >> I have successfully built the 64bit cross compiler for cygwin64. There
> >> are no changes to the -1 release other than some .cygport modifications.
> >>
> >> For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the
> >> 32bit cygwin hits release, I will push it there too.
> >>
> >> There are some files in the package that replaces some of the
> >> mingw-w64-headers CRT headers, this is done on purpose. will
> >> cygcheck/setup have any issues?
> >>
> >> Since it is not in any major distros, I guess it will have to go through
> >> a vote.
> > 
> > Isn't that rather just a necessary library extensions to the cross
> > toolchain?  I'm not so sure we really need a vote here.  Feel free
> > to upload.
> > 
> > Btw., would you mind to release new 32 bit w32api headers and runtime?
> > The latest changes to include the intrinsics in kernel32.a were pretty
> > important fixes for the Cygwin toolchain I think.
> > 
> 
> OK, I'll only be free to do it this weekend though.

Sure, no worries.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1

2013-04-08 Thread JonY
On 4/8/2013 15:57, Corinna Vinschen wrote:
> On Apr  7 17:47, JonY wrote:
>> winpthreads is a pthreads implementation from mingw-w64. The ABI is
>> incompatible with pthreads-win32. One of the major differences is that
>> winpthreads uses scalar handles, so it is a bit more compatible to other
>> packages that assume int type handles.
>>
>> I have successfully built the 64bit cross compiler for cygwin64. There
>> are no changes to the -1 release other than some .cygport modifications.
>>
>> For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the
>> 32bit cygwin hits release, I will push it there too.
>>
>> There are some files in the package that replaces some of the
>> mingw-w64-headers CRT headers, this is done on purpose. will
>> cygcheck/setup have any issues?
>>
>> Since it is not in any major distros, I guess it will have to go through
>> a vote.
> 
> Isn't that rather just a necessary library extensions to the cross
> toolchain?  I'm not so sure we really need a vote here.  Feel free
> to upload.
> 
> Btw., would you mind to release new 32 bit w32api headers and runtime?
> The latest changes to include the intrinsics in kernel32.a were pretty
> important fixes for the Cygwin toolchain I think.
> 

OK, I'll only be free to do it this weekend though.





signature.asc
Description: OpenPGP digital signature


Re: 64bit: segfault : recv return type ?

2013-04-08 Thread Corinna Vinschen
On Apr  8 10:00, Corinna Vinschen wrote:
> On Apr  7 19:12, marco atzeri wrote:
> > On 4/7/2013 9:06 AM, marco atzeri wrote:
> > >On 4/6/2013 11:10 PM, Corinna Vinschen wrote:
> > 
> > >>What is the original code doing?
> > >>
> > >>
> > >>Corinna
> > >>
> > 
> > 
> > I think the problem in on recv definition.
> > [...]
> > recv 4294967295
> > before for n  4294967295
> > [MARCOATZERI:03904] *** Process received signal ***
> > [MARCOATZERI:03904] Signal: Segmentation fault (11)
> > -
> > 
> > so recv is returning 2^32-1 instead of the expected -1
> > 
> > 
> > on winsup/cygwin/net.cc is defined as function returning int
> > ---
> > /* exported as recv: standards? */
> > extern "C" int
> > cygwin_recv (int fd, void *buf, size_t len, int flags)
> > {
> >   int res;
> > 
> >   fhandler_socket *fh = get (fd);
> > 
> >   myfault efault;
> >   if (efault.faulted (EFAULT) || !fh)
> > res = -1;
> > ---
> > 
> > while on sys/socket.h
> > ssize_t recv (int, void *__buff, size_t __len, int __flags);
> > 
> > on POSIX
> >   http://pubs.opengroup.org/onlinepubs/009695399/functions/recv.html
> > 
> > (and also
> >newlib/libc/sys/linux/net/recv.c return ssize_t)
> > 
> > while:
> > sizeof(int) = 4
> > sizeof(ssize_t) = 8
> 
> You're oh so right.  Thanks for tracking this down.  I'll fix that asap.

Should be fixed in CVS.  I'll create a new 64 bit Cygwin DLL later today.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: 64bit: segfault : recv return type ?

2013-04-08 Thread Corinna Vinschen
On Apr  7 19:12, marco atzeri wrote:
> On 4/7/2013 9:06 AM, marco atzeri wrote:
> >On 4/6/2013 11:10 PM, Corinna Vinschen wrote:
> 
> >>What is the original code doing?
> >>
> >>
> >>Corinna
> >>
> 
> 
> I think the problem in on recv definition.
> [...]
> recv 4294967295
> before for n  4294967295
> [MARCOATZERI:03904] *** Process received signal ***
> [MARCOATZERI:03904] Signal: Segmentation fault (11)
> -
> 
> so recv is returning 2^32-1 instead of the expected -1
> 
> 
> on winsup/cygwin/net.cc is defined as function returning int
> ---
> /* exported as recv: standards? */
> extern "C" int
> cygwin_recv (int fd, void *buf, size_t len, int flags)
> {
>   int res;
> 
>   fhandler_socket *fh = get (fd);
> 
>   myfault efault;
>   if (efault.faulted (EFAULT) || !fh)
> res = -1;
> ---
> 
> while on sys/socket.h
> ssize_t recv (int, void *__buff, size_t __len, int __flags);
> 
> on POSIX
>   http://pubs.opengroup.org/onlinepubs/009695399/functions/recv.html
> 
> (and also
>newlib/libc/sys/linux/net/recv.c return ssize_t)
> 
> while:
> sizeof(int) = 4
> sizeof(ssize_t) = 8

You're oh so right.  Thanks for tracking this down.  I'll fix that asap.


Thank you,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1

2013-04-08 Thread Corinna Vinschen
On Apr  7 17:47, JonY wrote:
> winpthreads is a pthreads implementation from mingw-w64. The ABI is
> incompatible with pthreads-win32. One of the major differences is that
> winpthreads uses scalar handles, so it is a bit more compatible to other
> packages that assume int type handles.
> 
> I have successfully built the 64bit cross compiler for cygwin64. There
> are no changes to the -1 release other than some .cygport modifications.
> 
> For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the
> 32bit cygwin hits release, I will push it there too.
> 
> There are some files in the package that replaces some of the
> mingw-w64-headers CRT headers, this is done on purpose. will
> cygcheck/setup have any issues?
> 
> Since it is not in any major distros, I guess it will have to go through
> a vote.

Isn't that rather just a necessary library extensions to the cross
toolchain?  I'm not so sure we really need a vote here.  Feel free
to upload.

Btw., would you mind to release new 32 bit w32api headers and runtime?
The latest changes to include the intrinsics in kernel32.a were pretty
important fixes for the Cygwin toolchain I think.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: [64bit RFU] emacs-24.3-3

2013-04-08 Thread Corinna Vinschen
On Apr  7 14:37, Andy Koppe wrote:
> On 6 April 2013 22:27, Corinna Vinschen wrote:
> > On Apr  6 16:50, Ken Brown wrote:
> >> D=http://sanibeltranquility.com/cygwin/64bit/release/emacs
> >> wget -x -nH --cut-dirs=3 \
> >>   ${D}/emacs-24.3-3-src.tar.bz2 \
> >>   ${D}/emacs-24.3-3.tar.bz2 \
> >>   ${D}/emacs-X11/emacs-X11-24.3-3.tar.bz2 \
> >>   ${D}/emacs-X11/setup.hint \
> >>   ${D}/emacs-debuginfo/emacs-debuginfo-24.3-3.tar.bz2 \
> >>   ${D}/emacs-debuginfo/setup.hint \
> >>   ${D}/emacs-el/emacs-el-24.3-3.tar.bz2 \
> >>   ${D}/emacs-el/setup.hint \
> >>   ${D}/emacs-w32/emacs-w32-24.3-3.tar.bz2 \
> >>   ${D}/emacs-w32/setup.hint
> 
> Done.
> 
> >> People testing these packages should be aware that the postinstall
> >> scripts will fail to set up the usual /usr/bin/emacs and
> >> /usr/bin/emacsclient symlinks because the alternatives package is
> >> not yet available.  So you will have to create your own symlinks if
> >> you want them.
> >
> > Unfortunately I can't upload.  The 64bit/release/emacs dir has only
> > write permissions for Andy Koppe.
> >
> > The same goes for yasm and libggi, which are 755 for Marco Atzeri
> > only.  This is weird, the release parent dir has 2775 permissions
> > and the subdirs should have the same permissions.
> 
> Sorry about that.
> 
> > Andy, Marco, can you please chmod -R g+w the aforementioned directories
> > ASAP?  Thank you.
> 
> Done, and umask adjusted in ~/.bashrc.

Thanks!


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: [64bit RFU] emacs-24.3-3

2013-04-08 Thread Corinna Vinschen
On Apr  7 16:57, marco atzeri wrote:
> On 4/6/2013 11:27 PM, Corinna Vinschen wrote:
> 
> >Unfortunately I can't upload.  The 64bit/release/emacs dir has only
> >write permissions for Andy Koppe.
> >
> >The same goes for yasm and libggi, which are 755 for Marco Atzeri
> >only.  This is weird, the release parent dir has 2775 permissions
> >and the subdirs should have the same permissions.
> >
> >
> >Andy, Marco, can you please chmod -R g+w the aforementioned directories
> >ASAP?  Thank you.
> 
> Done

Thanks!


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat