| Re: [AD] Windows binary compatibility |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
if we remove the sorting of allegro.def i'm pretty sure the result from
dllwrap --output-def will be the same, which means the dlls produced without
export definition file are compatible with those generated by using the
export definition file. but that remains to be seen. it's not really THAT
important to get rid of the export definition files anyway, it's just a
niceness. ;o) in my eyes preventing internals from beeing exported is much
more important. currently there's some #ifndef SCAN_EXPORT hacks in
aintern.h to ensure binary compatibility between dlls that use c drawing
code as opposed to the dlls that use asm drawing code. these can be removed
once eric has finished the job.
i don't understand why you say maintaining binary compatibility will be a
pain? the export definitions will be 'set in stone'(tm) unless somebody
changes the API...
-henrik
----- Original Message -----
From: Eric Botcazou <ebotcazou@xxxxxxxxxx>
To: Allegro Conductors <conductors@xxxxxxxxxx>
Sent: Sunday, May 20, 2001 9:26 AM
Subject: Re: [AD] Windows binary compatibility
> > Do we need to recompile it?
>
> No, this is the test.
>
> > If not, then it doesn't work here (MSVC 6.0 sp5, Win2k pro sp1)
> > I get:
> > "The ordinal 1331 could not be located in the dynamic link library
> > all3937.dll"
>
> Oh My God ! (TM) Looks like I was totally wrong (and Shawn right).
> At least we are now sure: MSVC links purely by symbol number, we need a
> compiler-independent export file and maintaining dll binary compatibility
> will be a pain.
>
> MSVC is crappy.
>
> Nice day ;-)
>
> --
> Eric Botcazou
> ebotcazou@xxxxxxxxxx
>
>