On Wed, 19 Nov 2008 14:38:19 +1100 David Gibson <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 18, 2008 at 12:47:52PM -0500, Josh Boyer wrote: > > Hi All, > > > > There's been a bug open for a while to get a libfdt shared > > library built in Fedora: > > > > http://bugzilla.redhat.com/show_bug.cgi?id=443882 > > > > This would have benefits for things like qemu and other > > applications that don't really need to statically link the > > libfdt.a into the binary itself. > > > > The reason we're waiting is because it would be best to > > have the upstream project define the soname and versioning > > that would be used. As mentioned in the bug, it could be > > as simple as using the base dtc version that it is split > > from, but for commonality reasons we'd want to settle on > > a single way to do it. That belongs upstream. > > > > So this is my plea for coming up with a solution. I can > > code up patches, but I thought some discussion would be > > proper first. > > Um.. well.. first for your immediate issue of getting libfdt into > Fedora, can I suggest you just use the static library. Sure, a shared > library would be nice, but libfdt is sufficiently small that I don't > think it's that bad to link statically with it. It's sort-of already in Fedora. At least the source is in DTC. However, Fedora has rules about static libraries and when they can be provided. I asked about this in the above bug report, but really what we're after is the shared version. > Longer term it would be nice to build a shared object of libfdt with > the rest. Soname is pretty easy to come up with, but we should > possibly also do symbol versioning for further security against future > changes breaking things. My current philosophy is to try very hard to > keep the libfdt API stable, but not try particularly hard to keep the > ABI stable. OK, fine by me. Do you want to continue on with that, or should I look at doing something along those lines? The symbol versioning part would take me a bit. josh _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
