On Tue, Jun 30, 2009 at 3:23 PM, Evan Stade<[email protected]> wrote: >>>> d) somehow use the system libjpeg for gtk, and our libjpeg for chrome >>> e) rename all symbols in our version of libjpeg, like was done in >>> libpng (see third_party/libpng/pngusr.h) >> >> And this one seems the safest to me. > > I don't think this works. To be more specific, the problem is that > client code is supposed to allocate space for certain structures. > Those structures include booleans. libjpeg checks to make sure the > passed in struct is equal in size to the expected struct size (i.e. > that against which it was compiled). Correct me if I misunderstood.
I don't fully understand the problem, so I'm more likely to be wrong. But I think you're saying is that GTK, as compiled against libjpeg, expects bools to be four bytes. I believe the only way our code can affect that is if we're overloading some libjpeg symbol to be our broken one -- any typedef'ing of boolean or whatever we do only affects code we're compiling, it won't affect the already existing code used within GTK to call into libjpeg. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
