<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Thomas,<br>
<br>
The real disadvantage I see is that for debian package users things
look different out of the box than for any other user. This is also
another flag that has to be tested on various platforms, not doing that
could cause problems later on. What about changing the behavior of
versioned_so=1? With the symbolic link things don't change really for
users, only for packaging we have todo some updates.<br>
<br>
Johnny<br>
<br>
On 05/14/2010 08:23 PM, Thomas Girard wrote:
<blockquote cite="mid:4BED952F.6040206@free.fr" type="cite">Hello,
  <br>
  <br>
for the Debian ACE+TAO packages we have decided to revert back to the
  <br>
traditional compilation method. But we also agreed to keep libtool-like
  <br>
library versioning scheme: libName-x.y.z.so instead of
libName.so.x.y.z.
  <br>
(e.g. libTAO_DynamicAny-1.7.7.so instead of libTAO_DynamicAny.so.1.7.7)
  <br>
  <br>
Rationale, already discussed in [0]: the meaning of 1.7.7 in the above
  <br>
example is really to show TAO's version. There is no intent to provide
  <br>
a hint or an ABI information.
  <br>
  <br>
The attached patch adds this new behavior when versioned_so=2.
  <br>
  <br>
Some remarks on the patch:
  <br>
&nbsp;- default versioning mechanism remains versioned_so=1. Hence without
  <br>
&nbsp;&nbsp; explicitely adding versioned_so=2 on make invocation this patch
  <br>
&nbsp;&nbsp; sould be a no-op.
  <br>
&nbsp;- soname of libraries was changed accordingly.
  <br>
&nbsp;- prj_install.pl was taught to copy these libraries as well.
  <br>
&nbsp;- tested on a Debian GNU/Linux i386 unstable box only.
  <br>
  <br>
Input needed on the following items:
  <br>
&nbsp;- rules.lib.GNU relies on a make macro definition, versioned_lib,
  <br>
&nbsp;&nbsp; defined differently for all three values 0, 1 and 2 of versioned_so.
  <br>
&nbsp;- rules.local.GNU does *not* rely on this macro because according to a
  <br>
&nbsp;&nbsp; comment at the beginning of the file it's possible that
  <br>
&nbsp;&nbsp; rules.lib.GNU does not get included in rules.local.GNU. Hence I
  <br>
&nbsp;&nbsp; wonder if it's useful to define a macro in rules.lib.GNU.
  <br>
&nbsp;- installation macro was not tweaked for vxworks. Would it be useful?
  <br>
  <br>
Last but not least: are you okay if I commit this patch to SVN?
  <br>
  <br>
Thanks,
  <br>
Regards,
  <br>
  <br>
Thomas
  <br>
  <br>
[0]
<a class="moz-txt-link-freetext" href="http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/f4790aadbdeb4679/5c43a557334afc69">http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/f4790aadbdeb4679/5c43a557334afc69</a>
  <br>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
devo-group mailing list
<a class="moz-txt-link-abbreviated" href="mailto:devo-group@list.isis.vanderbilt.edu">devo-group@list.isis.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://list.isis.vanderbilt.edu/mailman/listinfo/devo-group">http://list.isis.vanderbilt.edu/mailman/listinfo/devo-group</a>
  </pre>
</blockquote>
</body>
</html>