Re: [Curses] Choose curses so library at startup (4/5)
Peter Berg Larsen <pebl(a)math.ku.dk> writes:
Changelog: - Try ncursesw, ncurses and curses so library before giving up at startup
You can't do that, there's no guarantee that the different libraries are binary compatible. We need to load the one we built against. -- Alexandre Julliard julliard(a)winehq.com
On Sat, 29 Nov 2003, Alexandre Julliard wrote:
Changelog: - Try ncursesw, ncurses and curses so library before giving up at startup
You can't do that, there's no guarantee that the different libraries are binary compatible. We need to load the one we built against.
I might be missing something here: The only thing we see by compiletime is headerfiles. At runtime we try dlopen a library what we hope corresponce to the headerfiles. There is no garantee that it is. I was under the impression (from reading ncurses docs/faq) that compatibility has prime focus. Even .so.4 is binary compatible with .so.5 if I have read it correct. Peter
Peter Berg Larsen <pebl(a)math.ku.dk> writes:
I might be missing something here: The only thing we see by compiletime is headerfiles. At runtime we try dlopen a library what we hope corresponce to the headerfiles. There is no garantee that it is.
That's why we get the soname at compile time, and dlopen that. It's not 100% foolproof, but it's the best we can do. But now if you open a different library, all bets are off, it has no reason to be compatible with the headers we used at compile time. -- Alexandre Julliard julliard(a)winehq.com
On Sat, 29 Nov 2003, Alexandre Julliard wrote:
Peter Berg Larsen <pebl(a)math.ku.dk> writes:
I might be missing something here: The only thing we see by compiletime is headerfiles. At runtime we try dlopen a library what we hope corresponce to the headerfiles. There is no garantee that it is.
That's why we get the soname at compile time, and dlopen that.
I dont follow you here? The soname comes from autoconf? (which compiles dummy.c and and looks at it with ldd)
It's not 100% foolproof, but it's the best we can do. But now if you open a different library, all bets are off, it has no reason to be compatible with the headers we used at compile time.
The existence of headers and sonames (versions) are test independently in autoconf (which I would see as a bug if they werent compatible). I would agree with you allmost any time. But (of cause there is a but) we are only using functions that was standard pre waaay old and I did actually spend some time looking for functions/types etc. and nothing has changed. As we are not touching internal stuff, allocating structs or termcap/terminfo etc. I am convinced that they are binary compatible (and I ran wine with some of the oldes curses lib I could find). Peter
I would agree with you allmost any time. But (of cause there is a but) we are only using functions that was standard pre waaay old and I did actually spend some time looking for functions/types etc. and nothing has changed. As we are not touching internal stuff, allocating structs or termcap/terminfo etc. I am convinced that they are binary compatible (and I ran wine with some of the oldes curses lib I could find).
the point is not only at function prototype level, lost of curses functions are defined as macros, and this can change from implementation to implementation. Hence the .so / header peering and the rest... A+ -- Eric Pouech
On Sun, 30 Nov 2003, Eric Pouech wrote:
I would agree with you allmost any time. But (of cause there is a but) we are only using functions that was standard pre waaay old and I did actually spend some time looking for functions/types etc. and nothing has changed. As we are not touching internal stuff, allocating structs or termcap/terminfo etc. I am convinced that they are binary compatible (and I ran wine with some of the oldes curses lib I could find).
the point is not only at function prototype level, lost of curses functions are defined as macros, and this can change from implementation to implementation. Hence the .so / header peering and the rest...
Yes you are right. But I ask for a pratical argument for why is shouldnt be binary compatible. The subset we are using is so small that is was defined (syntax and sematics) mandentory for a curses library back in 95 (before linux 2.0.0). Looking at this subset in the ncurses code shows that functions/types/structs/macroes have not changes since.
participants (3)
-
Alexandre Julliard -
Eric Pouech -
Peter Berg Larsen