On Tue, Mar 06, 2012 at 09:47:40AM +0100, Sebastian Trüg wrote:
> to be honest: I did not know that this was even possible. I would gladly
> apply this to upstream Soprano if you could provide a generic non-Debian
> specific patch.
I'm not very cmake literate, so I probably won't be able to provide a
generic patch on my own. Maybe one of the Debian KDE maintainers can help?
Effectively what we need is an implementation of findVirtuosoDriver() in
cmake:
return Soprano::findLibraryPath( "virtodbc_r", QStringList(), QStringList()
<< QLatin1String( "virtuoso/plugins/" ) << QLatin1String( "odbc/" ) );
We can't use find_library() because this isn't strictly speaking a library
(it has no soname, it's not named "lib<foo>.so" so we can't link against it
with -l); it's a DSO, and it happens to be possible to link against DSOs
when using glibc, and it happens to be *safe* in this case because we have a
stable ABI as defined by ODBC. I don't know if there's a similar cmake
idiom for finding DSOs. I guess you can use find_path()?
And as I said, linking to a DSO isn't portable to all Unices. So the code
should probably still give preference to libiodbc if it's available.
> Also did you test this? Did you run the Virtuoso unit test?
I ran virtuosobackendtest from the tree, which I think is what you're
referring to. Linking directly to virtodbc_r.so gives the same test results
as linking to libiodbc (23 pass, 3 fail).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
> On 03/06/2012 08:47 AM, Steve Langasek wrote:
> > Hi Sebastian, nice to meet you!
> >
> > On Tue, Mar 06, 2012 at 01:34:45AM +0100, Pino Toscano wrote:
> >
> >> Alle martedì 6 marzo 2012, Steve Langasek ha scritto:
> >>> I'm surprised to say that after sitting on this bug for far too long,
> >>> it turns out that it's trivial to fix. Although it had been
> >>> reported that soprano would not work with unixodbc, once I actually
> >>> installed virtuoso, which the soprano test suite silently depends
> >>> on, I get the same results from test/virtuosobackendtest when built
> >>> against either iODBC or UnixODBC.
> >
> >> I remember Sebastian Trueg (main soprano upstream) strongly recommending
> >> against using unixODBC (e.g. in [2], just last September), so I'm not
> >> sure whether this switch would break anything in the semantic desktop
> >> stack.
> >> (Disclaimer: I don't use Nepomuk myself.)
> >
> >> Sebastian, what is the current status of soprano wrt unixODBC/iODBC?
> >> Which problems would result in using unixODBC?
> >
> >> [2] http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso-
> >> clucene-and-libstreamanalyzer/
> >
> > Right, so I've read the comment in that blog entry about needing libiodbc
> > because of RDF extensions. But I've reviewed the libiodbc source, and can't
> > find any evidence that such extensions exist - there's a single RDF define
> > in the iodbcext.h header, but a copy of this header is shipped in the
> > soprano source and there are no uses of the define anyway. As best as I can
> > tell, the only extensions are in the virtuoso driver, which libiodbc2 merely
> > passes the requests through to - and unixodbc would appear to do the very
> > same.
> >
> > The one thing I have found that's different between iODBC and UnixODBC (but
> > not represented in the previous patch) is that UnixODBC will not allow
> > look-up of a driver by filename alone; it requires that the filename match
> > the filename for a driver registered with odbcinst.ini. This seems like a
> > feature that we could patch into UnixODBC easily enough if needed. (And
> > apparently there was something wrong with my previous testing that I didn't
> > catch this.)
> >
> > However, I wonder why it makes sense for soprano to use a driver manager at
> > all, given that it appears soprano can *only* use the virtuoso driver as a
> > backend. Wouldn't it be simpler to call into the virtuoso driver directly
> > and omit the driver manager, on Unix?
> >
> > Attached is a revised patch to the Debian that implements the above
> > proposal. Since UnixODBC is no longer involved (except as a provider of the
> > sql.h header) there should not be any compatibility issues here. It may not
> > be portable to non-Linux systems, but maybe it would be an acceptable distro
> > patch, Pino?
> >
> >>> I'm happy to upload this as an NMU if you would like. It's probably
> >>> worth an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to
> >>> migrate to testing, since it's hard to have usable ODBC drivers for
> >>> soprano until it's fixed.
> >
> >> We're currently just started our KDE 4.7 transition, which includes also
> >> a soprano update from 2.6 to 2.7; if possible, I think IMHO it would be
> >> desiderable to wait for such dependency change, in case, after the
> >> transition is over (hopefully in two weeks, if everything goes fine).
> >> Would this timeframe suit you?
> >
> > I think it makes perfect sense to not upload this change until we're
> > confident it's not going to be a problem for the transition.
> >
> > Cheers,
>
--
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120307041217.ga26...@virgil.dodds.net
