the recent dl loader fixes break builds with DoLoadableServer set to NO.
Attached patch is an attempt to fix.
Maybe LoaderSymbol should be turned into a macro instead ?
Created attachment 552 [details] [review]
better yet, i'll just remove all the remaining calls to LoaderSymbol in the
drivers. i knew it was a hack to begin with. still a valid point though, we
ought to no-op the loader API when doing a loader-free build.
assigning to me.
I would like to check in Mattheiu's patch until you have time to finish the dll
loader work, so that work can proceed on other bugs.
Created attachment 555 [details] [review]
i'd rather do something like this. applies against CVS HEAD without Mattheiu's
Created attachment 559 [details] [review]
supplements to version 2
Your patch works here (OpenBSD/amd64), except for 2 missing parts from my
original patch, and one typo.
Verified that with your version 2 patch and Matthieu's supplemental patch, the
build completes. Could you go ahead and check in these patches?
checked in, closing. thanks for the review.
I get now a warning with the patches checked in, which our (SuSE) build system
(i386) treats as fatal ("Program is likely not 64bit clean. Please investigate
and fix") and fails.
mga_storm32.c: In function `Mga32AccelInit':
mga_storm32.c:748: warning: implicit declaration of function
mga_storm32.c:748: warning: assignment makes pointer from integer without a
Could you please have a look at this? The changes of the other drivers don't
suffer from a similar problem.
Looks like there was a typo in mga_storm.c in Matthieu's supplemental patch
- infoPtr->CacheMonoStipple = LoaderSymbol("XAACachePlanarMonoStipple");
+ infoPtr->CacheMonoStipple = XAACachePlanarMonoStippleWeak();
Well there's a problem with declaration of pointers to functions in the patch.
I'm fixing these now.