Ralf Wildenhues <ralf.wildenh...@gmx.de> writes:
> * Simon Josefsson wrote on Wed, Apr 01, 2009 at 06:50:07AM CEST:
>> Bruno Haible <br...@clisp.org> 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
