Hi Axel,
> And as Philippe has pointed out, the most probable cause is that you
> don't link against the dictionary objects. The exports are only
> relevant if you create a shared lib containing your objects, and you
> want to link against that shared lib. Looking at the output you've
> attached to your emails this doesn't seem to be the case.
I think I am lost in the terminology.
I have a set of analysis code that uses my personal TMatrixQ class,
which is like TMatrixD only with long double instead of Double_t
elements. I need to implement on Windows now - the financial world uses
Windows. I stripped out my personal class and used TMatrixD when I moved
stuff to Windows because I wanted to avoid build trouble in .NET... My
.dll file, which is a plug-in for Excel, worked great, but gave me
different answers from the Linux analysis with the same inputs and same
code (with the TMatrixD substitution). This code I describe so far has a
.def file that "exports" the one function call to Excel (or to my text
executable, or any other .exe that would use my .dll), but this might
not be the "export" you are talking about.
Anyway, I must put TMatrixQ back in. I made a separate area called
root_extend, just like I have in my Linux libraries, with separate build
rules in .NET to reflect what Francois-Xavier's page says. TMatrixQ
depends on ROOT more heavily than the rest of the to-be-implemented code
because TMatrixQ (and TArrayQ, TMatrixQUtils, TVectorQ) inherits from
TObject and needs all that Cint stuff.
So you think I can address my TMatrixQ problems with dictionary work
only, and without making an "export library"? Or do you now agree with
Valeri?
- John
--
Dr. John Krane
jkrane@netzero.com
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:07 MET