This would certainly make things a lot easier. One issue I can think
of is that we currently bundle a modified sqlite, and nss uses sqlite.
Part of the plan was for our bundled nss to use our sqlite (since
that's another 32-bit lib which is missing on Hardy). We can still do
this with borrowed .so's, but I'm not sure if our changes to sqlite
would have any implications for nss compiled against a different
version (someone more familiar with our sqlite changes might know if
this is an issue or not).
Michael
On Thu, Feb 26, 2009 at 9:48 AM, Dean McNamee <de...@chromium.org> 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.
>
> On Thu, Feb 26, 2009 at 6:42 PM, Adam Langley <a...@chromium.org> wrote:
>>
>> On Thu, Feb 26, 2009 at 9:26 AM, Michael Moss <mm...@chromium.org> wrote:
>>> include nss and nspr directly in our build, thus bypassing any issues
>>> with missing system libs.
>>
>> Also note that, for the people using git, it's all in the history now
>> anyway so it doesn't matter to us if it ever gets removed.
>>
>>
>> AGL
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
