On Sunday 15 July 2007, Nishanth Aravamudan wrote: > > @@ -145,11 +146,11 @@ > > > > obj32/libhugetlbfs.so: $(LIBOBJS:%=obj32/%) > > @$(VECHO) LD32 "(shared)" $@ > > - $(CC32) $(LDFLAGS) -shared -o $@ $^ $(LDLIBS) > > + $(CC32) $(LDFLAGS) -Wl,-soname,$@ -shared -o $@ $^ $(LDLIBS) > > > > obj64/libhugetlbfs.so: $(LIBOBJS:%=obj64/%) > > @$(VECHO) LD64 "(shared)" $@ > > - $(CC64) $(LDFLAGS) -shared -o $@ $^ $(LDLIBS) > > + $(CC64) $(LDFLAGS) -Wl,-soname,$@ -shared -o $@ $^ $(LDLIBS) > > Makes sense. What is the functional change here, though? That is what > does having a proper "soname" do? (I've looked at the ld manpage, but > it's still not quite clear).
while having a SONAME when the library itself is not [currently] using ABI versioning in its name, it's arguable whether SONAME serves a purpose. in the face of no DT_SONAME tag in the ELF shared lib, ld will just encode the linked name. so in the case of libhugetlbfs, these values are currently the same. if you start doing things with ABI versioning like: libhugetlbfs.so.1.0 libhugetlbfs.so.1 -> libhugetlbfs.so.1.0 libhugetlbfs.so -> libhugetlbfs.so.1 then you'll need the soname so that ld knows to encode DT_NEEDED as "libhugetlbfs.so.1" instead of just "libhugetlbfs.so". so to answer your question simply, at this very moment in time, because of the way ld behaves (it will guess a SONAME if you dont encode one), linking with -Wl,-soname gains you nothing except it makes some automatic ELF QA checkers not warn. down the road, it will be needed if you start using ABI numbers if the filename. > If you could resubmit with a Signed-off-by line and in -p1 format, I'll > apply the patch and it will be in the next release (I expect to be ready > for 1.2-rc1 soon). attached Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> > Does this mean libhugetlbfs will be available via portage? it already is per the request of someone who wanted it ... honestly, i know nothing about hugetlbfs ;) -mike
signature.asc
Description: This is a digitally signed message part.
--- libhugetlbfs/Makefile +++ libhugetlbfs/Makefile @@ -13,9 +13,10 @@ INSTALL = install -LDFLAGS = --no-undefined-version -Wl,--version-script=version.lds -CFLAGS = -O2 -Wall -fPIC -g -CPPFLAGS = -D__LIBHUGETLBFS__ +LDFLAGS += --no-undefined-version -Wl,--version-script=version.lds +CFLAGS ?= -O2 -g +CFLAGS += -Wall -fPIC +CPPFLAGS += -D__LIBHUGETLBFS__ ARCH = $(shell uname -m | sed -e s/i.86/i386/) @@ -145,11 +146,11 @@ obj32/libhugetlbfs.so: $(LIBOBJS:%=obj32/%) @$(VECHO) LD32 "(shared)" $@ - $(CC32) $(LDFLAGS) -shared -o $@ $^ $(LDLIBS) + $(CC32) $(LDFLAGS) -Wl,-soname,$@ -shared -o $@ $^ $(LDLIBS) obj64/libhugetlbfs.so: $(LIBOBJS:%=obj64/%) @$(VECHO) LD64 "(shared)" $@ - $(CC64) $(LDFLAGS) -shared -o $@ $^ $(LDLIBS) + $(CC64) $(LDFLAGS) -Wl,-soname,$@ -shared -o $@ $^ $(LDLIBS) obj32/%.i: %.c @$(VECHO) CPP $@ @@ -206,7 +206,7 @@ @$(VECHO) OBJSCRIPT $* sed "s!### SET DEFAULT LDSCRIPT PATH HERE ###!HUGETLB_LDSCRIPT_PATH=$(LDSCRIPTDIR)!" < $< > $@ -install: all $(OBJDIRS:%=%/install) $(INSTALL_OBJSCRIPT:%=objscript.%) +install: libs $(OBJDIRS:%=%/install) $(INSTALL_OBJSCRIPT:%=objscript.%) @$(VECHO) INSTALL $(INSTALL) -d $(DESTDIR)$(LDSCRIPTDIR) $(INSTALL) -m 644 $(INSTALL_LDSCRIPTS:%=ldscripts/%) $(DESTDIR)$(LDSCRIPTDIR)
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
