Re: Customizing soname
Alon Bar-Lev wrote: 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. So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get result. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/29/08, Roumen Petrov [EMAIL PROTECTED] wrote: So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get result. Thanks! It works. Although I am sure I tried this in several notations, and in all I got automake error that this must not be none constant. Strange... I still think that libtool should enable soname to be customized :) Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote: On 3/29/08, Roumen Petrov [EMAIL PROTECTED] wrote: So with automake makefile like this : lib_LTLIBRARIES = @[EMAIL PROTECTED] @[EMAIL PROTECTED] = module.c @[EMAIL PROTECTED] = -module -avoid-version where MODULE is substituted by configure you can get result. Thanks! It works. Although I am sure I tried this in several notations, and in all I got automake error that this must not be none constant. Strange... I still think that libtool should enable soname to be customized :) May be is good libtool to preserve some variables from CONFIG_SITE file (libname_spec, soname_spec, etc ??? ) . In was my case http://lists.gnu.org/archive/html/libtool/2007-07/msg00044.html . It is similar to you case since I would like to be able to define name of library file on a particular platform(host), but I don't like to change library internal name (soname). Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
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
Re: Customizing soname
Alon Bar-Lev wrote: Hello, I had an issue that I solved in patching libtool, I am not sure this was the right thing to do, but if it was, I think it should go into libtool. I require to produce a shared library that whose name is customizable by the user. Why? I can understand wanting to change the extension, we have -shrext for that. But why do you want the user to have the option to set the name? Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/27/08, Peter O'Gorman [EMAIL PROTECTED] wrote: Why? I can understand wanting to change the extension, we have -shrext for that. But why do you want the user to have the option to set the name? Hi! Because I generate a plugin, each configuration results in different plugin. I also have this when I produce proxy shared library. I can do this very simple with automake/libtool if I rename the output. But not got any solution of how to correct the soname. Maybe I can do this with some ELF hacking utility, but I think that adding the ability to override the soname via libtool is the simplest and cleanest. Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote: On 3/27/08, Peter O'Gorman [EMAIL PROTECTED] wrote: Why? I can understand wanting to change the extension, we have -shrext for that. But why do you want the user to have the option to set the name? Hi! Because I generate a plugin, each configuration results in different plugin. I also have this when I produce proxy shared library. I can do this very simple with automake/libtool if I rename the output. But not got any solution of how to correct the soname. Maybe I can do this with some ELF hacking utility, but I think that adding the ability to override the soname via libtool is the simplest and cleanest. Does automake complain if you do something like: @PLUGIN_TARGET@: foo.lo $(LIBTOOL) --mode=link --tag=CC $(CCLD) -o @PLUGIN_TARGET@ \ foo.lo -avoid-version -module install-exec-hook: @PLUGIN_TARGET@ $(LIBTOOL) --mode=install $(INSTALL) @PLUTIN_TARGET@ \ $(DESTDIR)$(libdir) ? Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/27/08, Peter O'Gorman [EMAIL PROTECTED] wrote: Does automake complain if you do something like: @PLUGIN_TARGET@: foo.lo $(LIBTOOL) --mode=link --tag=CC $(CCLD) -o @PLUGIN_TARGET@ \ foo.lo -avoid-version -module install-exec-hook: @PLUGIN_TARGET@ $(LIBTOOL) --mode=install $(INSTALL) @PLUTIN_TARGET@ \ $(DESTDIR)$(libdir) ? Hi, Yes, I can write my own automake rules. But then I have to reverse engineer each automake version and add AM_CFLAGS, AM_LDFLAGS, CFLAGS, LDFLAGS, target specific flags, or anything automake generates. I expected libtool to allow override these kind of settings... So I proposed to add -soname argument. I think it is very simple and may make live easier if needed. But if you totally against adding this I will consider maintaining specific automake rules. Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
* Alon Bar-Lev wrote on Thu, Mar 27, 2008 at 06:35:48PM CET: On 3/27/08, Peter O'Gorman [EMAIL PROTECTED] wrote: Why? I can understand wanting to change the extension, we have -shrext for that. But why do you want the user to have the option to set the name? Because I generate a plugin, each configuration results in different plugin. Is the set of possible names limited? If yes, please read http://www.gnu.org/software/automake/manual/html_node/Conditional-Libtool-Libraries.html Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
On 3/28/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Is the set of possible names limited? If yes, please read http://www.gnu.org/software/automake/manual/html_node/Conditional-Libtool-Libraries.html Hi, No... Sorry... I need to produce a different name chosen by configure and/or user. But exactly in the spirit of -rpath I believe -soname should be added... :) Thanks! Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Customizing soname
Alon Bar-Lev wrote: On 3/28/08, Ralf Wildenhues [EMAIL PROTECTED] wrote: Is the set of possible names limited? If yes, please read http://www.gnu.org/software/automake/manual/html_node/Conditional-Libtool-Libraries.html Hi, No... Sorry... I need to produce a different name chosen by configure and/or user. But exactly in the spirit of -rpath I believe -soname should be added... :) -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. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
