Global 32/64 bit collision issues

Corinna Vinschen
Mon May 27 10:04:00 GMT 2013

On May 26 21:29, Yaakov (Cygwin/X) wrote:
> On 2013-05-23 03:44, Corinna Vinschen wrote:
> >However, there are a couple of packages which change the system on a
> >global basis.  I see three groups here:
> [...]
> >    This would require to change the service installer scripts to check
> >    on what platform they are running and then attaching the "64" suffix
> >    if `uname -m' returns "x86_64".
> >
> >    An alternative would be to change cygrunsrv so that the 64 bit
> >    version always attaches the "64" automatically.  While this is easy
> >    to accomplish, I see a problem here because the name change is not
> >    transparent to the user, nor to scripts.
> I suggest changing the installer scripts, as duplicates do not make
> sense for all services.
> >    Having said that, the name change from "cron" to "cron64" is also
> >    kind of cumbersome.  Usually you only need one service, either the 32
> >    or the 64 bit version, but not both.  So, do we want the name change
> >    at all?
> Some of these aren't so clear cut:
> * cron
> While due to the purpose it serves, one may suffice, only that
> crontabs must be configured within the same Cygwin root.  OTOH, that
> itself may depend on what people are putting in their crontabs in
> the first place.
> * clamd
> Provides either or both of local socket and TCP connections; the
> former is the default.  One will suffice for both if the network
> mode is (also) enabled.

Local socket won't work, unless you store the local socket outside
the cygwin install tree, something a default installer script should
not do or rely upon, IMHO.

> Other "OS services" however, which are accessed only via local
> socket or the like, would need to be installed and running for both:
> * messagebus (D-Bus system bus)
> * avahi-daemon (uses messagebus)
> * syslogd/syslog-ng

I question that in terms of syslog-ng.  You always have the Windows
log.  Installing Syslog-ng is more fun than necessity, isn't it?

> * and...
> >    But what about cygserver?  Without cygserver there's no XSI IPC.
> >    Even if we don't change the service names on a general basis,
> >    shouldn't cygserver at least be available in parallel, using
> >    different service names?
> IMO yes.

I guessed.

I'm kind of cringing when thinking of a naming convention for the 64 bit
packages.  Not only that it looks weird in the service list:


it's also a nuisance when starting/stopping the service.  You now longer
start the service, you start the service64, even if you don't have a 32
bit installation on that machine.  ANybody having a *good* idea for a
naming convention?

In the end, we want users to have only one installation, either 32 bit
or 64 bit, and the latter should be preferred on 64 bit machines anyway.
So I'm still wondering if we really should bother at all.  The only
"users" running both installations in parallel are maintainers and
Cygwin devs, isn't it?  And those, I trust, know what they are doing.
Is that too simple?


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

More information about the Cygwin-apps mailing list