This is the mail archive of the
mailing list for the Cygwin project.
Corinna Vinschen <vinschen at redhat dot com>
- From: Brian Ford <ford at vss dot fsi dot com>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 22 Jul 2003 13:59:34 -0500 (CDT)
- Subject: Corinna Vinschen <vinschen at redhat dot com>
On Tue, Jul 22, 2003 at 20:45:23PM +0200, Corinna Vinschen wrote:
>On Tue, Jul 22, 2003 at 12:25:51PM -0500, Brian Ford wrote:
>> I compile the program stuff.exe that depends upon the non-rebuilt dll
>> foo.dll. No interfaces between stuff.exe and foo.dll were changed in
>> 1.5.0, but foo.dll calls lseek.
>> Now, when lseek in foo.dll is resolved at link time with the 1.5.0
>> cygwin1.dll, lseek resolves to lseek64. But foo.dll wanted plain old
>> Do I have this right, or am I still seriously confused?
>Confused, I guess. You're mixing link time with load time. Link
>time is when gcc (actually ld) creates the dll. Load time is when
>the dll is loaded into memory on demand of an application linked
>against symbols in that dll.
>The dependency on lseek has been resolved at link time, the time when
>foo.dll has been created. Therefore, if foo.dll expects lseek, it gets
>lseek on load time.
>When rebuilding foo.dll, the dependency to lseek is converted to a
>dependency on lseek64 in the created dll already at link time.
>`nm foo.dll' will show you the symbol lseek64. When foo.dll is loaded
>into memory it expects to get lseek64 now.
That makes me feel a lot better.
Just one last clarification. If stuff.exe also calls lseek, it will get
lseek64 at link time, and foo.dll will still use lseek. So, they each
operate seperately, but happily, be it in their respective 64 or 32 bit
Thanks a lot for your patience.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems