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: RFC: Cygwin 64 bit?


On 8/7/2011 8:02 AM, Corinna Vinschen wrote:
> On Aug  7 07:55, Charles Wilson wrote:
>> On 8/7/2011 7:52 AM, Charles Wilson wrote:
>>> The 64bit version of run and run2 would be problematic -- these apps are
>>> specifically intended to be the "top of a tree"; that is, started from
>>> Windows and not "mintty". And not via a batch file either, since that
>>> would rather defeat their purpose.
>>
>> Ditto startxwin:
>>
>> Found: C:\cygwin-1.7\bin\startxwin.exe
>> C:\cygwin-1.7\bin\startxwin.exe
>>   C:\cygwin-1.7\bin\cygX11-6.dll                <<<<<
>>     C:\cygwin-1.7\bin\cyggcc_s-1.dll            <<<<<
>>       C:\cygwin-1.7\bin\cygwin1.dll
>>         C:\Windows\system32\ADVAPI32.DLL
>>           C:\Windows\system32\ntdll.dll
>>           C:\Windows\system32\KERNEL32.dll
>>           C:\Windows\system32\RPCRT4.dll
>>     C:\cygwin-1.7\bin\cygxcb-1.dll              <<<<<
>>       C:\cygwin-1.7\bin\cygXau-6.dll            <<<<<
>>       C:\cygwin-1.7\bin\cygXdmcp-6.dll          <<<<<
>>
>> And here, we don't even have the option of supplying the exe as a
>> statically linked binary, because the X libs are DLL-only.

Actually, this is wrong. Sortof. It *used* to be the case that we only
had DLLs for the X libs, but now Yaakov ships both dll+dll.a, and .a.
However, I must admit to being a bit perplexed by the following:

-rw-r--r-- 1 user group 114750 Apr 28  2010 /usr/lib/libxcb.a
-rwxr-xr-x 1 user group 340880 Apr 28  2010 /usr/lib/libxcb.dll.a

How can a simple import library, that only contains thunks to functions
actually defined in the DLL, be twice the size of the static library --
which presumably contains the actual implementations OF those functions.

A similar pattern seems to prevail for all of the X libs I checked. Odd.

> Dynamic linking 

I suppose.  Since all of these apps are under our direct control (e.g.
no "upstream" to worry about) we can do what we want.

> could fix that problem.  Except for cyggcc_s-1.dll,
> but apparently the depencies to cyggcc_s-1.dll will be much reduced
> with a newer GCC.

Yeah, that one's tricky.  It's hard to initialize all the pre-main()
stuff without cyggcc_s-1.dll, but if push comes to shove we can use
-statie-libgcc.

--
Chuck


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