This is the mail archive of the
mailing list for the Cygwin project.
Re: Waiting for xfree86? [Was: guile-1.6.4-1]
- From: Brian Ford <ford at vss dot fsi dot com>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 22 Jul 2003 12:25:51 -0500 (CDT)
- Subject: Re: Waiting for xfree86? [Was: guile-1.6.4-1]
On Mon, Jul 21, 2003 at 15:54:29 -0400, Christopher Faylor wrote:
>On Mon, Jul 21, 2003 at 08:17:44PM +0200, Jan Nieuwenhuizen wrote:
>>Christopher Faylor <email@example.com> writes:
>>> Why are we waiting for these libraries? Do they export variables or
>>> functions which rely on new 64 bit types?
>>I haven't investigated that. It's just that they are listed in:
>I suspect that Chuck was a little overzealous in listing packages. As I
>have been saying (and saying, and saying...) there is no need to rebuild
>a package unless its interface has changed.
A clarification question again. Sorry.
If a package is rebuilt, and it links with non-rebuilt libraries,
will there be trouble even if the non-rebuilt libraries do not
export interfaces that changed? Maybe my definition of "interfaces that
changed" is wrong, or maybe I don't understand the method still, but here
is an example.
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?
Thanks for your patience.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems