Customizing soname

2008-03-27 Thread Alon Bar-Lev

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.

I use autoconf/automake/libtool in order to build the system.

I must use libtool to create libraries, from the obvious reason of creating
proper libraries in all archs.

automake cannot get modified name as rules, so I expected something
like that work:

lib_LTLIBRARIES=m1
m1_SOURCES=
m1_LDFLAGS=$(AM_LDFLAGS) -module -avoid-version -no-undefined \
-soname @CONFIG_SONAME@

install-exec-hook:
mv "$(DESTDIR)$(libdir)/m1.so" "$(DESTDIR)$(libdir)/@CONFIG_SONAME@"

But I have found no way to make libtool to accept my soname. I've read most
of the script, and found no way to do it.

In the end I ended up with the attached patch, which enable the use of -soname 
argument.
This is for 1.5 series. But I've read the 2.X branch and found no solution 
there either.

As far as I undersand any other solution make the Makefile.am much more complex,
and forces me to write my own rules for building and installing my libray.

Can you please consider adding a way to specify the soname as libtool argument?

Thanks,
Alon Bar-Lev.

---

--- libtool.org 2008-03-27 16:08:34.0 +0200
+++ libtool 2008-03-27 16:09:07.0 +0200
@@ -2034,6 +2034,11 @@ EOF
continue
;;
 
+  -soname)
+prev="soname_spec"
+   continue
+   ;;
+
   # -64, -mips[0-9] enable 64-bit mode on the SGI compiler
   # -r[0-9][0-9]* specifies the processor on the SGI compiler
   # -xarch=*, -xtarget=* enable 64-bit mode on the Sun compiler


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Customizing soname

2008-03-27 Thread Peter O'Gorman
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

2008-03-27 Thread Alon Bar-Lev
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

2008-03-27 Thread Peter O'Gorman
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

2008-03-27 Thread Alon Bar-Lev
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: MinGW linux to win32 cross compiler and the test suite

2008-03-27 Thread Roumen Petrov

Erik de Castro Lopo wrote:

Hi all,

I have the beginnings of a solution to this issue.

If I hack the libtool generated wrapper script and replace this:

  exec "$progdir/$program" ${1+"$@"}

with 


  WINEDLLPATH="$PATH;$WINEDLLPATH"
  exec wine "$progdir/$program" ${1+"$@"}

My test suite works. Ie, I cross compile from Linux to win32 and
the test suite gets run under wine. Personally, I find this an
huge improvement over developing on windows.

I now have a follow up question. Would it be possible/desirable to
have autoconf/automake/libtool do the following:

  1) Detect if cross-compiling from x86 linux to win32.
  2) If 1) is true, detect precence of wine.
  3) If 2) is true and wine is present, write a wine specific
 version of the output wrapper scripts.

Cheers,
Erik



Just setup binfmt-support.

Roumen






___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Customizing soname

2008-03-27 Thread Ralf Wildenhues
* 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


Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: Customizing soname

2008-03-27 Thread Alon Bar-Lev
On 3/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Is the set of possible names limited?  If yes, please read
>  
> 

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

2008-03-27 Thread Peter O'Gorman
Alon Bar-Lev wrote:
> On 3/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> Is the set of possible names limited?  If yes, please read
>>  
>> 
> 
> 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