Re: Customizing soname
On 3/28/08, Peter O'Gorman [EMAIL PROTECTED] wrote: -rpath is required for proper execution in many environments, the ability to change the soname is, as far as I can tell, not. Please present a more convincing argument. Hello Peter, I think that infrastructures such as libtool should allow customization of any attribute that affect the output. Of course there should be defaults but it should allow overriding to allow customization. This especially true when the customization is simple to implement and to maintain. Your example of not using automake simplified rules in order to workaround the lack of ability to customize the soname attribute is correct. But it is a workaround that makes build system much more complex, just because customization is missing. What you recommend is instead the following automake rules: lib_LTLIBRARIES=module1.la module1_la_SOURCES=m1.c m2.c m3.c m4.c module1_la_LDFLAGS=-module -avoid-version -soname @MYNAME@ install-exec-local: install-libLTLIBRARIES mv -f $(DESTDIR)$(libdir)/module1.so $(DESTDIR)$(libdir)/@MYNAME@ Write the following make rules: LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) CCLD = $(CC) my_objects=m1.lo m2.lo m3.lo m4.lo @MYNAME@: $(my_objects) $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ -module -avoid-version $(LDFLAGS) -o $@ \ -rpath $(libdir) $(my_objects) $(LIBS) lib_LTLIBRARIES=#create install-exec-hook: install-libLTLIBRARIES @MYNAME@ $(LIBTOOL) --mode=install $(INSTALL) @MYNAME@ \ $(DESTDIR)$(libdir) all-local: @MYNAME@ .c.lo: if am__fastdepCC $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $ mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo else if AMDEP source='$' object='$@' libtool=yes @AMDEPBACKSLASH@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ endif $(LTCOMPILE) -c -o $@ $ endif It is doable... But in what price? Patching libtool with three lines to add ability to override soname and use 5 line simple automake rules. Or write complex build rules and remove/add parts if automake chooses to not generate/generate libtool stuff, and maintaining these complex rules of about 30 lines. I know what I choose. As far as I understand the soname is one of the few last attributes that cannot be overridden, I don't understand who not enable this and not forcing users to create complex rules if required. It is simple enough to support this... Without breaking ABI or any other past interface. Thank you for your time, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On Fri, 28 Mar 2008, Alon Bar-Lev wrote: I think that infrastructures such as libtool should allow customization of any attribute that affect the output. Of course there should be defaults but it should allow overriding to allow customization. This especially true when the customization is simple to implement and to maintain. Since libtool is portability software, each requested feature needs to be evaluated based on its impact to portability and its usefulness on many platforms. Your request is the first I can recall for supporting the ability to customize soname. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote:
On 3/28/08, Peter O'Gorman [EMAIL PROTECTED] wrote:
-rpath is required for proper execution in many environments, the
ability to change the soname is, as far as I can tell, not.
Please present a more convincing argument.
Hello Peter,
I think that infrastructures such as libtool should allow customization
of any attribute that affect the output. Of course there should be defaults
but it should allow overriding to allow customization. This especially true
when the customization is simple to implement and to maintain.
Your example of not using automake simplified rules in order to
workaround the lack of ability to customize the soname attribute
is correct. But it is a workaround that makes build system much
more complex, just because customization is missing.
What you recommend is instead the following automake rules:
lib_LTLIBRARIES=module1.la
module1_la_SOURCES=m1.c m2.c m3.c m4.c
module1_la_LDFLAGS=-module -avoid-version -soname @MYNAME@
install-exec-local: install-libLTLIBRARIES
mv -f $(DESTDIR)$(libdir)/module1.so $(DESTDIR)$(libdir)/@MYNAME@
Write the following make rules:
LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
$(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
CCLD = $(CC)
my_objects=m1.lo m2.lo m3.lo m4.lo
@MYNAME@: $(my_objects)
$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
-module -avoid-version $(LDFLAGS) -o $@ \
-rpath $(libdir) $(my_objects) $(LIBS)
lib_LTLIBRARIES=#create
install-exec-hook: install-libLTLIBRARIES @MYNAME@
$(LIBTOOL) --mode=install $(INSTALL) @MYNAME@ \
$(DESTDIR)$(libdir)
all-local: @MYNAME@
.c.lo:
if am__fastdepCC
$(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $
mv -f $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
else
if AMDEP
source='$' object='$@' libtool=yes @AMDEPBACKSLASH@
DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
endif
$(LTCOMPILE) -c -o $@ $
endif
But you request is not what I expect from soname:
$echo void foo(void) {} module.c
$ gcc -shared -o module.so -Wl,-soname=test.so module.c
$ objdump -x module.so | grep SONAME
SONAME test.so
$ /sbin/ldconfig -v -l module.so
test.so - module.so
You request is to change library name. So I could not understand what is
related to SONAME. It came as a surprise to me to allow user(verdor) to
change library name at configure time.
Roumen
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Hello Bob, Alon, * Bob Friesenhahn wrote: Your request is the first I can recall for supporting the ability to customize soname. There was an earlier, much more elaborate one, by Keith Packard, http://thread.gmane.org/gmane.comp.gnu.libtool.general/6213. And we never applied anything there *because* there was no patch that was nicely portable, or even degrade gracefully on lesser capable platforms, IIRC. * Alon Bar-Lev wrote: It is doable... But in what price? Patching libtool with three lines to add ability to override soname and use 5 line simple automake rules. Or write complex build rules and remove/add parts if automake chooses to not generate/generate libtool stuff, and maintaining these complex rules of about 30 lines. Well, I haven't looked much at your 30 lines of Makefile.am, but I can tell you maintaining those 30 lines is going to be *far less* hassle than getting -soname support right. install-exec-local: install-libLTLIBRARIES mv -f $(DESTDIR)$(libdir)/module1.so $(DESTDIR)$(libdir)/@MYNAME@ FWIW, it's custom that 'install*' targets copy files, not move them. Ideally, 'make install' should not modify an up to date build tree at all (however, even libtool breaks this rule sometimes). FWIW2, if you believe modules are named *.so on all kinds of interesting systems, nope. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Roumen Petrov [EMAIL PROTECTED] wrote: You request is to change library name. So I could not understand what is related to SONAME. It came as a surprise to me to allow user(verdor) to change library name at configure time. It for generating a differnet module using automake. At the end SONAME matches the module name. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: There was an earlier, much more elaborate one, by Keith Packard, http://thread.gmane.org/gmane.comp.gnu.libtool.general/6213. I believed I am not the first one... :) Did not find this specific thread though. But... For each report you usually have many people that solves this in a different (long, unmaintained and even incorrect) way, or fail to. And we never applied anything there *because* there was no patch that was nicely portable, or even degrade gracefully on lesser capable platforms, IIRC. Can you please explain (As I don't understand) how allowing to override soname when generating a module makes it less portable? I truly don't understand... If user specify soname and system does not support soname, it is ignored. If system do support soname, then developer has reason to override this. If a user does not specify soname you keep current behavior. Well, I haven't looked much at your 30 lines of Makefile.am, but I can tell you maintaining those 30 lines is going to be *far less* hassle than getting -soname support right. I am truly sorry... But I fail to understand this statement as-is. FWIW2, if you believe modules are named *.so on all kinds of interesting systems, nope. Sorry... I can detect this part at configure. I thought about creating another thread after this one... As libtool *KNOWS* the extension to use, it can place this on autoconf variable... Or add the following: libtool --mode=getvar shrext libtool --mode=getvar libext Thank you, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
