This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: RFC: Cygwin 64 bit?


On 2:59 PM, Corinna Vinschen wrote:
>> What does Linux do?
> 
> Executables in /{s}bin, /usr/{s}bin, regardless of 32 or 64 bit.
> Libs in /lib vs. /lib64, /usr/lib vs. /usr/lib64.
> 
>> (Also, do libraries still need to go into the same directory as executables?)
> 
> Yes, %PATH% still rulez.

Which means that the 64bit dlls *must* have a different name, or we
can't have coexistence.  E.g.
  bin/app1.exe is not yet ported to 64, and uses (32bit) cygz-1.dll
  bin/app2.exe IS ported to 64, so obviously needs the (64bit) zlib dll?
If a 64bit zlib DLL is available, then we need to have both installed,
without conflicts -- which means (a) different DLL name OR different
location for both 64bit DLLs AND EXEs, and (b) different PACKAGE name.

Oops.

So, if 64 and 32 are to coexist in the same installation, we need to
worry not just about DLL names, but also the name of packages (at least,
for delivery of DLLs).

Currently, most package sets that deliver general purpose (i.e.
non-private) DLLs do so in a separate "library" package (zlib,
ironically, being an exception):

tiff
tiff-doc
tiff-opengl
libtiff-devel

>>> libtiff6 <<<

Now, on my (64bit) linux box, the following two packages do not conflict
(*).

libtiff-3.9.5-1.fc15.x86_64
libtiff-3.9.5-1.fc15.i686

So, the first observation is that the "package name" includes the
bitness of the binary. None of our package names do this, at present
(not counting the mingw64 cross compilers).



Now, in the linux case, the .so's themselves DO have the same name --
they just get installed into separate directories:

/usr/lib64/libtiff.so.3.9.5
/usr/lib/libtiff.so.3.9.5

However, if we only have one 'bin' directory for both 32 and 64 bit
exe/dlls, then...we need to give the DLLs different names, as well. I
like the prefix idea -- and I'll push it on libtool if necessary.


(*) Well, they do, but not with regards to the shared libraries
themselves.  Both linux packages install the following:
/usr/share/doc/libtiff-3.9.5/COPYRIGHT
/usr/share/doc/libtiff-3.9.5/README
/usr/share/doc/libtiff-3.9.5/RELEASE-DATE
/usr/share/doc/libtiff-3.9.5/VERSION


>>>  - Do we define "long" as 32 bit or 64 bit type?
>>
>> Oooh, that's a difficult one. (For anyone who doesn't know: It's 64
>> bits on Linux, but 32 bits on Windows, including MinGW-64.)
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
> bugs me.  There's no _CS_POSIX_V7_xxx definition which allows for 32
> bit int, 32 bit long, 64 bit pointer and 64 bit off_t.

Yep.  sizeof(long) != sizeof(void*)...Bad Microsort! No cookie!

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]