> The problem is that both Apache::Request and Apache::Cookie link in > libapreq (statically). You can "use" one *or* the other in a given > mod_perl-enabled process, but if you try to "use" both, they both > publish the same libapreq's symbols, and you get a symbol clash.
That is kind of weird, why isn't this the case on other platforms? > One hacky solution is to have libapreq linked statically in with the > binary, then let the dynamic Apache/Request.so satisfy the libapreq > from there. That's the approach taken by this proffered solution. To > me... it seems an odd hack to have to make the core binary provide > callbacks needed by second-tier shared libs. :( I agree, an odd hack indeed! > Of course, the only way I could get mod_perl to pull in .so's is to > link it statically, which also seems odd. How could Apple have > screwed up the linker and dynloader so much? I have no clue! :-) Maybe that's why I got a malloc error with the Apple-provided so and not with the static custom one > Kyle> I don't know about custom-built dynamic ones, I just rebuilt my > Kyle> mod_perl static and this worked well. > > Until you use both Apache::Request and Apache::Cookie, then Booom! Well, yes, but in any case I was referring to my statically linked mod_perl not suffering from the same instability as the .so one _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
