On Thu, Feb 26, 2009 at 10:03 AM, Wan-Teh Chang <[email protected]> wrote: > On Thu, Feb 26, 2009 at 9:48 AM, Dean McNamee <[email protected]> wrote: >> >> I don't understand why we need to import all of this code just so we >> can build an .so. >> >> Why don't we just take the .so's from the 32-bit package we're already >> using, and stick them into our .deb? We can check them into svn if >> don't want developers to have to have it, but that problem is already >> solved by the install script. >> >> Tracking third_party source (security updates, etc) is a huge pain, >> and has caused a lot of problems in the past. Also, having to build >> it seems pointless. > > This idea also occurred to me. Chromium only needs the NSS/NSPR > headers and the .so's for Linux. > > The only issue is that the NSS/NSPR .so's we check into the source > tree need to work on all x86 Linux distributions that we support. I > don't know the state of binary compatibility across Linux distributions > today. Perhaps it works -- I believe that's how Adobe distributes its > Flash plugins. > > Another idea is to work harder with Ubuntu to provide the "ia32" > NSPR/NSS libs for x86_64 in Ubuntu 8.04 LTS. That'd be the best > solution but require a lot of red tape.
For those who haven't been following this whole saga, note that there is an Ubuntu bug for this, and so far they have been unwilling to backport it to Hardy. They applied a fix (unfortunately broken) to Intrepid, but don't seem inclined to muck with Hardy unless it's a security fix. At this point, any new requests would be targeted to Jaunty by default. Michael --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
