Re: [TCLCORE] Tcl/Tk 8.6b1 Release Candidates

[Kevin K. <ke...@ac...>]

Adam Williamson:
>>> Just one question about the tdbc thing: it's installed
>>> in /usr/lib/tdbc1.0b1 but includes a tdbcConfig.sh file whose contents
>>> implies it may be used as a directly linked library. In this usage case,
>>> how do you expect the app that links against it to be able to find it?
>>> Subdirectories of /usr/lib are not usually in ld's path.

Joe English:
>> Tcl applications and extensions will not normally link against
>> libtdbc directly [*].  Normally, Tcl applications dynamically
>> load the *.so file, and extensions link against the lib*stub.a file.

Adam Williamson:
> Yes, this I know. However, look at tdbcConfig.sh:
> 
> TDBC_LIB_SPEC="-L/usr/lib -ltdbc1.0b1"
> TDBC_STUB_LIB_SPEC="-L/usr/lib -ltdbcstub1.0b1"
> 
> The second is for linking against the stub lib, obviously. However, the
> first isn't. It would link against the .so file, the 'plugin'.
> 
> If this should never ever happen, by policy, then tdbc should not
> include a provision for it to happen.

"Should never ever happen, by policy" is too strong a phrase
for what's going on.  "Shouldn't happen in a regular old binary
distribution" is closer to the truth.  There are a few people
who, for special purposes, build their own applications that
link everything statically. To do this, they configure Tcl
and all needed extensions --disable-shared, and then concoct
a link unit that includes Tcl and all necessary extensions
as static libraries. The only case where <module>_LIB_SPEC
would be needed is to support such a build. It appears that
TEA's configurator fills in <module>_LIB_SPEC in all cases,
but actually tries to build and install the library only in
a --disable-shared build.

I actually haven't yet tested a --disable-shared build of
TDBC, partly because it's not something that I expect downstream
distributors to do. A fully-static build of Tcl is an unusual
beast, and those who embed Tcl in this fashion are using
self-built libraries the whole way, and used to needing a
certain amount of tinkering when moving to a new release.

I'm far from convinced that there is actually going to
be any downstream demand for a --disable-shared version of
tdbc, and if we have to fix TEA to make it work, it's
probably best to cross that bridge when we come to it.

[some additional dialog snipped... leading up to a question
about the correct installation path for tdbcConfig.sh]

> Yes, I noticed that. =) I should ask the Fedora guy to clarify it. I
> guess it should be in /usr/lib, otherwise I'm not sure whatever wants to
> use it would be able to find it.
> 
>> and "TEA"
>> doesn't have any clear guidelines about this either.
>> Probably safest to leave it in the package directory, i.e.,
>> %{tcl_sitearch}/%{name}%{version}/, for now.
> 
> See above...this is probably 'right', but I'm not sure it'd work. Do we
> have any test case apps that actually use tdbc so I can see what they
> do?

The prototypical user of tdbc at this point is the tdbc::odbc
bridge, which you can find in the upstream tdbc repository at
<URL:http://tdbc.tcl.tk/>.  I'm all for figuring out The Right Thing
for TEA to handle cross-package dependencies. I seem to recall
that the TEA_PATH_CONFIG and TEA_LOAD_CONFIG autoconf macros,
which are there for the purpose, didn't actually *work* in all
cases, and that some builds needed to resort to --with-tdbc=
and --with-tcloo= to get them right.

Fortunately, cross-package dependencies at the binary level
are rare. Most Tcl packages interact only at the script level,
and only a handful even export Stubs. So there shouldn't be
a ton of tinkering in dependent packages to fix this.

-- 
73 de ke9tv/2, Kevin