Re: Is it possible to dynamize "requires" at RPM build time?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2006-08-23 at 23:34 +0200, Kai Engert wrote:
> Tomas Mraz wrote:
> > On Wed, 2006-08-23 at 16:31 -0400, Jesse Keating wrote:
> >   
> >> On Wednesday 23 August 2006 16:18, Hans de Goede wrote:
> >>     
> >>> Actually afaik gnome and gtk have the exact same problem (they are fully
> >>> backward compatible but introduce new symbols making apps using these
> >>> new symbols break on older version), but there we've been plastering
> >>> over the problem by manually adding Requires to packages.
> >>>       
> >> I just talked to some of our Gnome maintainers and they don't think that's the 
> >> case at all.
> >>
> >> Isn't that why you have foo-so.1 and foo-so.1.1?  Your build that has 
> >> foo-so.1.1 could include foo-so.1 for compat no?  Am I totally off base here?  
> >> Versioned libraries are here for a reason, so that you can know what soname 
> >> you're compiling against and need later on down the road.  Having random 
> >> symbols in random unversioned .so files seems very very wrong to me, as a 
> >> shared library.
> >>     
> >
> > No, they would have to use versioned symbols for this purpose.
> >
> > See http://people.redhat.com/drepper/dsohowto.pdf section 3.
> >   
> 
> Exported symbol in NSS shared libraries are tagged with the number of 
> the first version that contained the symbol. I used this command to grep 
> for the new symbols in the most recent FC5 update:
> 
> [root@kaiez1 tmp]# readelf -a /usr/lib/libnss3.so |grep -i 3\.11\.1
>    230: 4f2ed4a0   320 FUNC    GLOBAL DEFAULT   11 
> NSS_RegisterShutdown@@NSS_3.11.1
>    553: 4f2ed400   151 FUNC    GLOBAL DEFAULT   11 
> NSS_UnregisterShutdown@@NSS_3.11.1
>    666: 4f3302e0    22 FUNC    GLOBAL DEFAULT   11 
> SEC_ASN1EncodeUnsignedInt@@NSS_3.11.1
>    749: 4f2f0fc0    86 FUNC    GLOBAL DEFAULT   11 
> SEC_RegisterDefaultHttpCl@@NSS_3.11.1
> (excerpt)
> 
> Kai

So the question becomes, why isn't the Firefox RPM requiring those
symbol versions?

nss3 provides them ("libnss3.so(NSS_3.3)", "libnss3.so(NSS_3.9.3)",
etc.), but the only thing that Firefox requires is "libnss3.so" and a
manally specified "nss >= 3.10".

Of course, I'm not sure this would actually help in the static archive
case that actually caused the problem here, but RPM should be picking up
the necessary symbol versions. libpipnss.so certainly requires them.

-- 
Nicholas Miell <nmiell@xxxxxxxxxxx>

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux