Re: pr-msvc-support: building .DLLs with symbols

[Peter Rosin]

Den 2009-09-22 02:15 skrev Christopher Hulbert:

On Mon, Sep 21, 2009 at 2:47 PM, Peter Rosin p...@lysator.liu.se wrote:

Den 2009-09-21 12:35 skrev Christopher Hulbert:

Apart from that, your suggestion will litter dependency_libs with
-LIBPATH: and it will not work for absolute paths (unless you're
using identity mounts, but that's cheating). That could perhaps be
fixed but I think you will have trouble converting back to a posix
path for dependency_libs in case of -L/absolute/path -
-LIBPATH:c:/some/mount/absolute/path. There's no api for that in
MSYS (that I know of).

I assume you mean the dependency_libs that gets written to the .la
file? My dependency_libs in Linux has a number of -L, but I'm not sure
if it is my patches. It seems to be in other packages that I have
downloaded and built as well, so I suspect that is the normal
behavior.

Yes it is normal with a bunch of -L options in dependency_libs. What
I'm objecting to is that with your version, it will be -LIBPATH:
instead of -L in dependency_libs. I see that as a problem (see below).


I am not sure what you mean by the identity mounts, could you explain
a little more?

Identity mount is where you put the MSYS root in the root of a
windows drive, so that /absolute/path means the same thing in
posix-land as in windows-land (given that you have the expected
current drive, e.g. C:).


Also, why would you want to convert back to a POSIX
path? If the compiler does not understand  posix path, there would be
no point that I could see to go back.

I want the .la file to contain -L and the POSIX paths, so that the
.la file is usable by MSYS/MinGW and looks as much as possible as in
the MSYS/MinGW case. That way the command line also looks the same
regardless of if the options came from dependency_libs or from
somewhere else.


I guess in my case, you would have to convert back (if possible) or
maintain 2 different variables. Neither is probably desired. I don't
mix compilers on Windows, so I guess I have not run into a case where
I want -L after converting to -LIBPATH:.


My philosophy has been to convert to MSVC style as late as possible,
and by doing so, keep a common code path with MinGW for as long as
possible. It probably also fits better if one package is built with
libtool/pr-msvc-support and some dependency/dependent package is
build with a cl.exe wrapper such as cccl. But that's a bit of
speculation as I'm not exactly a heavy cccl user...


And you still need some way to get FLAG in behind that -link
option in case someone feeds you -Wl,FLAG (which is a much better
way to feed -LIBPATH: options from the outside, compared to having
libtool also recognize -LIBPATH: as an alias for -L IMHO), or you
are stuck with moving options to an envvar (or a command file).

I consider myself a libtool hacker (not a libtool developer), but it
looks like the -Wl argument modifies a linker_flag variable. Why
not just add that, like deplibs, after the -link in the archive_cmds
and archive_expsym_cmds that is defined in libtool.m4? Then, it would
put those arguments after -link.

And only do that for MSVC case only, which will force some other variable
to enable the code path at all, since we don't want to foul up the
command line for saner cases. But certainly doable, but I fail to see
the advantage over using the LINK envvar.


And I would disagree that feeding in the libpath via a bunch of -Wl
is good. For example, how does an autoconf macro check for a library.
Right now with my hacked libtool and a macro I wrote that emulates
AC_TRY_LINK and AC_LINK_IFELSE using libtool to compile, my autoconf
macros that check for libraries can just build up the -Lpath -la
link information based on a directory passed into the configure
argument. Otherwise, I (or another builder of my packages) would have
to specify all the -LIBPATH and library files manually. I personally
find this much cleaner for building.

You misunderstood me, I meant that

.../libtool ... -Wl,-LIBPATH:C:/foo/bar -lgazonk

is better than

.../libtool ... -LIBPATH:C:/foo/bar -lgazonk

I don't see any reason to support

.../libtool ... -LIBPATH:C:/foo/bar -lgazonk

at all (unless you have -LIBPATH: in dependency_libs of course, but
that's not clean IMHO).


I guess I don't see a reason not to, but maybe we just don't have the
same goals.


In that case it's because you have more limited goals. The end result
of your approach is that everything is pulled into the MSVC world, and
nobody hasn't even got a remote chance of seamless integration when
using the result with MinGW (or whatever).


One issue I am not sure how you address, is that the
linker does not interpret -ljunk as libjunk.lib, junk.lib, etc. I
search the directories in deplibs for the library and translate it
from -l to something the compiler/linker would understand.


There is code for that in the pr-msvc-support branch. Have a look
at this patch:
http://savannah.gnu.org/patch/?6446
commit 452faf96f7b06e9eccee01553d95c45080d1cc29

And this 

Improve versioning algorithm description

[Ralf Wildenhues]

The current text in the Updating version info node is seen as hard to
understand by some users, IIRC we've had a few reports about this in the
past.  Richard made me try to reformulate it now.

What do you think about this additional explanation?
OK to apply (and ok to add you to THANKS, Richard)?

Thanks,
Ralf

Improve versioning algorightm documentation.

* doc/libtool.texi (Updating version info): Repeat the
algorithms in different, hopefully simpler terms.
* THANKS: Update.
Report by Richard B. Kreckel and others, several times.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index 08a44c4..cb6ec80 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2879,6 +2879,37 @@ Instead, use the @option{-release} flag (@pxref{Release 
numbers}), but be
 warned that every release of your package will not be binary compatible
 with any other release.
 
+The following explanation may help to understand the above rules a bit
+better: consider that there are three possible kinds of reactions from
+users of your library to changes in a shared library:
+
+...@enumerate 1
+...@item
+Programs using the previous version may use the new version as
+drop-in replacement, and programs using the new version can also work
+with the previous one.  In other words, no recompiling nor relinking
+is needed.  In this case, bump @var{revision} only, don't touch
+...@var{current} nor @var{age}.
+
+...@item
+Programs using the previous version may use the new version as
+drop-in replacement, but programs using the new version may use APIs not
+present in the previous one.  In other words, a program linking against
+the new version may fail with ``unresolved symbols'' if linking against
+the old version at runtime: set @var{revision} to 0, bump @var{current}
+and @var{age}.
+
+...@item
+Programs may need to be changed, recompiled, relinked in order to use
+the new version.  Bump @var{current}, set @var{revision} and @var{age}
+to 0.
+...@end enumerate
+
+...@noindent
+In the above description, @emph{programs} using the library in question
+may also be replaced by other libraries using it.
+
+
 @node Release numbers
 @section Managing release information
 

Re: Improve versioning algorithm description

[Bob Friesenhahn]

On Tue, 22 Sep 2009, Ralf Wildenhues wrote:


The current text in the Updating version info node is seen as hard to
understand by some users, IIRC we've had a few reports about this in the
past.  Richard made me try to reformulate it now.

What do you think about this additional explanation?
OK to apply (and ok to add you to THANKS, Richard)?


This explanation is very useful.  Please apply.

Bob

   Improve versioning algorightm documentation.

   * doc/libtool.texi (Updating version info): Repeat the
   algorithms in different, hopefully simpler terms.
   * THANKS: Update.
   Report by Richard B. Kreckel and others, several times.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index 08a44c4..cb6ec80 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -2879,6 +2879,37 @@ Instead, use the @option{-release} flag (@pxref{Release 
numbers}), but be
warned that every release of your package will not be binary compatible
with any other release.

+The following explanation may help to understand the above rules a bit
+better: consider that there are three possible kinds of reactions from
+users of your library to changes in a shared library:
+
+...@enumerate 1
+...@item
+Programs using the previous version may use the new version as
+drop-in replacement, and programs using the new version can also work
+with the previous one.  In other words, no recompiling nor relinking
+is needed.  In this case, bump @var{revision} only, don't touch
+...@var{current} nor @var{age}.
+
+...@item
+Programs using the previous version may use the new version as
+drop-in replacement, but programs using the new version may use APIs not
+present in the previous one.  In other words, a program linking against
+the new version may fail with ``unresolved symbols'' if linking against
+the old version at runtime: set @var{revision} to 0, bump @var{current}
+and @var{age}.
+
+...@item
+Programs may need to be changed, recompiled, relinked in order to use
+the new version.  Bump @var{current}, set @var{revision} and @var{age}
+to 0.
+...@end enumerate
+
+...@noindent
+In the above description, @emph{programs} using the library in question
+may also be replaced by other libraries using it.
+
+
@node Release numbers
@section Managing release information





--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: Improve versioning algorithm description

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Wed, Sep 23, 2009 at 05:19:26AM CEST:
 On Tue, 22 Sep 2009, Ralf Wildenhues wrote:
 
 The current text in the Updating version info node is seen as hard to
 understand by some users, IIRC we've had a few reports about this in the
 past.  Richard made me try to reformulate it now.
 
 What do you think about this additional explanation?
 OK to apply (and ok to add you to THANKS, Richard)?
 
 This explanation is very useful.  Please apply.

The most important question is whether it is correct, not only for
Linux.  That's what I'm not yet certain about.

Thanks,
Ralf

Re: Improve versioning algorithm description

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Wed, Sep 23, 2009 at 05:47:55AM CEST:
 On Wed, 23 Sep 2009, Ralf Wildenhues wrote:
 
 The most important question is whether it is correct, not only for
 Linux.  That's what I'm not yet certain about.
 
 Something tells me that it is not correct for Windows.  Under
 Windows I see a lack of versioning and libtool adds a simple number
 like name-7.dll to the name.  Not all OSs support library
 versioning, so in that case applications would continue using the
 older library and freshly compiled applications would use the newer
 library.

That is the same with systems which only provide static linkage.
We cannot do anything against that; only, we shouldn't imply in
the documentation that the user can expect anything better either.

Aside, most systems where $major is not $current-$age will need
relinking after a compatible API update (case 2).  This is the
more relevant case I'm thinking of, I guess most users know about
the case of totally featureless versioning.

Cheers,
Ralf

Re: Improve versioning algorithm description

[Charles Wilson]

Bob Friesenhahn wrote:
 On Wed, 23 Sep 2009, Ralf Wildenhues wrote:

 The most important question is whether it is correct, not only for
 Linux.  That's what I'm not yet certain about.
 
 Something tells me that it is not correct for Windows. 

Ralf's description is correct also for Windows.

 Under Windows I
 see a lack of versioning and libtool adds a simple number like
 name-7.dll to the name.  Not all OSs support library versioning, so in
 that case applications would continue using the older library and
 freshly compiled applications would use the newer library.

Thru the magic of 'c-a', on windows we can represent one dimensional
compatibility (that is, backwards compatibility) with a single number.
That is:

old app -- old dll, ok.
old app -- new compatible dll, ok
new app -- new compatible dll, ok
new app -- old dll, maybe ok, maybe not.

The old dll may not be forward compatible with new applications, even
though the new dll is backwards compatible with old applications, and
thus both DLLs have the same single number.

From Ralf's three cases:
case 1) no API change at all, c and a do not change -- DLL is forward-
and backward- compatible, and 'c-a' remains constant so DLL name doesn't
change.  This is correct behavior.

case 2) API additions only. DLL is backwards-compatible, but not
forward-compatible. Both c and a are incremented, so 'c-a' does not
change, and DLL name doesn't change. This is correct behavior.

case 3) API deletions or modifications. DLL is not compatible. c in
incremented, and a is set to 0. No matter how you slice it, 'c-a' will
change -- and the DLL name will change with it.  This is correct behavior.


See this page for a good example:
http://home.att.net/~perlspinr/libversioning.html

--
Chuck