Re: ld-output-def

[Simon Josefsson]

Ralf Wildenhues <address@hidden> writes:

> * Simon Josefsson wrote on Wed, Apr 01, 2009 at 06:50:07AM CEST:
>> Bruno Haible <address@hidden> writes:
>> > Your documented example looks like this:
>> >
>> >> +if HAVE_LD_OUTPUT_DEF
>> >> +libfoo_la_LDFLAGS += -Wl,--output-def,libfoo-$(SOVERSION).def
>> >> +defexecdir = $(bindir)
>> >> +defexec_DATA = libfoo-$(SOVERSION).def
>> >> +DISTCLEANFILES += $(defexec_DATA)
>> >> +endif
>> >
>> > What is $(SOVERSION) ? As I understand it, libfoo-$(SOVERSION).def should
>> > match the basename of libfoo-$(SOVERSION).dll, right? But that basename is
>> > determined by libtool from the L:T:V triple that gets passed as
>> > -version-info argument, in an undocumented (platform dependent) way.
>> 
>> I forgot this aspect.  The application needs to compute the SOVERSION
>> field from the values passed to libtool.  Assuming the projects uses:
>> 
>> AC_SUBST(LT_CURRENT, 1)
>> AC_SUBST(LT_REVISION, 1)
>> AC_SUBST(LT_AGE, 0)
>> ...
>> libgss_la_LDFLAGS = -no-undefined \
>>      -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
>> 
>> It can compute the SOVERSION value as follows:
>> 
>> SOVERSION=`expr ${LT_CURRENT} - ${LT_AGE}`
>> AC_SUBST(SOVERSION)
>> 
>> I'll include this in an updated version of the patch.
>
> But this requires the user to know the particular version computation
> for this one system.

--output-def is documented to only works for EXE targets, and those
systems (Windows) uses that version computation.

> Worse even, the generic name `SOVERSION' easily implies to the naive
> user that this version holds for all systems this package may be built
> upon.  That can't be sensible.

This is an example in the documentation, but I have changed so that it
uses the hopefully less confusing variable name DLL_VERSION.

>> > Right? Then, the --output-def functionality should be available
>> > through libtool. We are not supposed to define and update manually an
>> > SOVERSION macro that is actually the result of some computations done by
>> > libtool.
>> 
>> DEF files are only relevant for windows targets, so I don't see any
>> point in having this functionality in libtool?
>
> I don't understand this argument.  AIUI you won't be using this
> functionality without libtool at all anyway, right?

It could be, since there is no assumptions in the M4 macro about
libtool.  But you are right that I won't use it without libtool.

> But even if, the above is an argument *for* including this
> functionality in libtool.

I'm not sure I see that -- but still, if the functionality is not in
libtool today, which I believe we can agree on, then gnulib is a good
place to work around such limitations meanwhile.

> I think all the functionality you need is contained in the
> pr-msvc-support branch of git Libtool.  Can you check whether that is
> sufficient for you?

I checked out the branch, but running a 'git diff -r
origin/pr-msvc-support..master' and searching for keywords like
'output-def', 'DEF', etc doesn't reveal anything.  How would I use this
libtool branch to output a DEF file?

As far as I could tell, the pr-msvc-support branch is for building
shared libraries using Visual Studio.  Is that right?

If so, that isn't what lib-msvc-compat is meant to help with:
lib-msvc-compat is for building a shared library, using mingw, and where
the user is a developer that wants to use the shared library from a
visual studio application.  Then a DEF file is useful.

/Simon