Hi Arthur,
> the generated vendor.dll.so file does contain the correct
> symbols but they are undefined.
By any chance is the vendor dll implemented in C++? If not, this
should work.
If so, you have a bit of a problem, and one that no-one has seriously
tried
to overcome (or at least if they ha
See if I understand what you need:
- vendor.dll (windows binary only)
- myapp.exe.so (winelib application that uses vendor.dll API and
compiles against "vendor" header files )
Check that you have done the following
1) wrote a vendor.dll.spec (spec syntax for all functions used from
"vendor" head
On December 9, 2003 08:14 pm, Kevin Cousins wrote:
> Compile and link against /that/ (or similar specialised for your
> particular situation), and you're undefined symbols will now have a
> definition, and your code should work as advertised. At the very least,
> all this worked for me!
Yes, it w
Arthur Bergman <[EMAIL PROTECTED]> writes:
> I have been trying to develop an application using a vendor provided
> dll from an external vendor to work under linux. If we develop the app
> on a windows box and move it over to the wine environment it works,
> but it would be preferable to have a mo
On Tue, 2003-12-09 at 23:58, Arthur Bergman wrote:
> If we develop the app on a windows box and move it over to the wine
> environment it works, but it would be preferable to have a more native
> approach. So I tried using winelib and have progressed to a point where
> I have an application that co
Hi,
I have been trying to develop an application using a vendor provided
dll from an external vendor to work under linux. If we develop the app
on a windows box and move it over to the wine environment it works, but
it would be preferable to have a more native approach. So I tried using
wineli
