D and msvcrt.dll

Is it possible to use libraries built with the msvcrt.dll runtime? I wanted to use the libxml2 library but the binary download page says:

http://www.zlatkovic.com/libxml.en.html

> Notes
>
> All binaries which you can download from this site use the multithreaded dynamic C-runtime (msvcrt.dll). Every program you compile using these binaries must use the same runtime. Unless you like your app crashing, set up your project to use msvcrt.dll. If you for some reason must use a different runtime, then you must get the source and compile libxml and friends yourself.

Can a D program use those libxml binaries?

Thanks

Carlos Peña
c-peña12_at_hotmail_dot_com

c-peña12@hotmail.com wrote:

>>like your app crashing, set up your project to use msvcrt.dll. If
>>you for some reason must use a different runtime, then you must get
>>the source and compile libxml and friends yourself.
> 
> 
> Can a D program use those libxml binaries?

As it says, you have to get the source and compile it yourself with DigitalMars C&C++ Compiler. This "issue" is not specific to D, it is just that you have to recompile the library for each other C compiler you are ging to use it with, or when the underlying C library gets major changes etc.

Besides, you'll need to write import libraries. Those are modules wrapped in extern(C){ ... } and consisiting only of prototypes you need and corresponding type definitions. It's mostly copy&paste since syntax is so similar.

-eye

In article <bvlfbm$min$1@digitaldaemon.com>, Ilya Minkov says...
>
>c-peña12@hotmail.com wrote:
>
>>>like your app crashing, set up your project to use msvcrt.dll. If you for some reason must use a different runtime, then you must get the source and compile libxml and friends yourself.
>> 
>> 
>> Can a D program use those libxml binaries?
>
>As it says, you have to get the source and compile it yourself with DigitalMars C&C++ Compiler. This "issue" is not specific to D, it is just that you have to recompile the library for each other C compiler you are ging to use it with, or when the underlying C library gets major changes etc.
>
>Besides, you'll need to write import libraries. Those are modules wrapped in extern(C){ ... } and consisiting only of prototypes you need and corresponding type definitions. It's mostly copy&paste since syntax is so similar.
>
>-eye
>

I'll try to rebuild the libraries my self then. I've read somewhere of a SWIG port for D, that could help me building the wrapers, right?

Thanks for your response.

<c-peña12@hotmail.com> wrote in message news:bvjl0u$kva$1@digitaldaemon.com...
> D and msvcrt.dll
>
> Is it possible to use libraries built with the msvcrt.dll runtime? I wanted to use the libxml2 library but the binary download page says:
>
> http://www.zlatkovic.com/libxml.en.html
>
> > Notes
> >
> > All binaries which you can download from this site use the multithreaded dynamic C-runtime (msvcrt.dll). Every program you compile using these binaries must use the same runtime. Unless you like your app crashing, set up your project to use msvcrt.dll. If you for some reason must use a different runtime, then you must get the source and compile libxml and friends yourself.
>
> Can a D program use those libxml binaries?

Probably not. The msvcrt.dll is very specific to Microsoft C++. Your best route to success would be to recompile libxml with DMC++, this will eliminate dependency on msvcrt.dll.

c-peña12@hotmail.com wrote:
> I'll try to rebuild the libraries my self then. I've read somewhere of a SWIG
> port for D, that could help me building the wrapers, right?

http://ikagames.com/andy/d/

However, i haven't tried it, but i think it will only be of help with (primarily C++ libraries which cannot be easily converted by hand) for which headers prepared for SWIG already exist.

There is another thing: you don't need wrappers, you only need declarations. What SWIG does (according to the manual), it kills most types and writes 2 layers of wrappers, which is more bloat than you need. This seems to be a design decision, because its primary purpose was to make communication between C/C++ and really off-the-ground languages possible, such as scripting (Perl, Python, Ruby) and languages with totally diverging typesystems, such as Sather. Besides, the effort of converting headers so that SWIG can understand them must also be considered.

There was a page from Mike Wynn on how C headers map to D imports, but it seems to have disappeared by now. There must be enough info in the docs though.

> Thanks for your response.

You're welcome!

-eye