On 01/19/2012 02:55 AM, Brian Smith wrote:
> Mike Hommey wrote:
>> But linux users are not necessarily up-to-date with the latest NSS. I
>> seriously doubt the number of users with the very last system nss
>> exceeds 10% of the linux user base except in exceptional "good
>> timing" cases (like when
On Thu, Jan 19, 2012 at 11:15:51AM -0500, John Dennis wrote:
> On 01/19/2012 07:26 AM, Mike Hommey wrote:
> >He is talking about runtime detection. Not build time detection. And we
> >already have --with-system-nss. My point is that it's probably not worth
> >trying to do runtime detection because
On 01/19/2012 07:26 AM, Mike Hommey wrote:
He is talking about runtime detection. Not build time detection. And we
already have --with-system-nss. My point is that it's probably not worth
trying to do runtime detection because few systems will have the right
system nss anyways.
I've been lurkin
Eitan Adler wrote:
> Brian Smith wrote:
> > If the system NSS isn't new enough, then Firefox's local version of
> > NSS would be used.
>
> From a packager point of view, please don't automagically detect
> these things. If the system NSS is supported provide an option
> --with-system-nss which if
On Thu, Jan 19, 2012 at 06:52:26AM -0500, Eitan Adler wrote:
> On Thu, Jan 19, 2012 at 3:55 AM, Brian Smith wrote:
> > Mike Hommey wrote:
> >> But linux users are not necessarily up-to-date with the latest NSS. I
> >> seriously doubt the number of users with the very last system nss
> >> exceeds 1
On Thu, Jan 19, 2012 at 3:55 AM, Brian Smith wrote:
> Mike Hommey wrote:
>> But linux users are not necessarily up-to-date with the latest NSS. I
>> seriously doubt the number of users with the very last system nss
>> exceeds 10% of the linux user base except in exceptional "good
>> timing" cases
Mike Hommey wrote:
> But linux users are not necessarily up-to-date with the latest NSS. I
> seriously doubt the number of users with the very last system nss
> exceeds 10% of the linux user base except in exceptional "good
> timing" cases (like when ubuntu is released with the latest version),
> b
On Wed, Jan 18, 2012 at 11:45:02PM -0800, Brian Smith wrote:
> Mike Hommey wrote:
> > > In the long run, for performance reasons, we should probably prefer
> > > the system NSS libraries to our own, whenever the system NSS
> > > libraries are available and are the right version, because at
> > > le
Mike Hommey wrote:
> > In the long run, for performance reasons, we should probably prefer
> > the system NSS libraries to our own, whenever the system NSS
> > libraries are available and are the right version, because at
> > least some of them are likely to already have been loaded into RAM
> > by
On Wed, Jan 18, 2012 at 02:44:34PM -0800, Brian Smith wrote:
> Mike Hommey wrote:
> > Please note that this is going to be a problem on systems that have
> > system nspr and nss libraries that other system libraries use.
>
> I am intending to avoid changing how NSS is linked on Linux, at least at
On Wed, Jan 18, 2012 at 2:44 PM, Brian Smith wrote:
> Mike Hommey wrote:
>> Please note that this is going to be a problem on systems that have
>> system nspr and nss libraries that other system libraries use.
>
> I am intending to avoid changing how NSS is linked on Linux, at least at the
> begi
Benjamin Smedberg wrote:
> I have no particular opinion about whether this is a good idea for
> NSS. I do think that we should not do this for NSPR unless we
> decide to remove support for binary XPCOM components in Firefox
> (per the ongoing discussion in dev.planning). Many of our XPCOM
> code pa
Mike Hommey wrote:
> Please note that this is going to be a problem on systems that have
> system nspr and nss libraries that other system libraries use.
I am intending to avoid changing how NSS is linked on Linux, at least at the
beginning. My priorities are are Android and Windows first, then M
- Original Message -
> From: "Benjamin Smedberg"
> To: "Brian Smith"
> Cc: "dev-platform" , "mozilla's crypto code
> discussion list"
>
> Sent: Wednesday, January 18, 2012 11:06:21 AM
> Subject: Re: Removal of NSS an
On 1/18/2012 1:30 AM, Brian Smith wrote:
they live in, and/or we may change the DLL we export those symbols from. This
will be a very positive footprint win, because it means that the linker will be
able to throw away the code for a lot of functions in NSPR and (especially) NSS
that are unused
15 matches
Mail list logo
