Using a mingw .dll with MSVC

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Using a mingw .dll with MSVC

Will Chappell
The short: How do I (if I can) use ming DLL's with Visual Studio?  (I
have read the ming FAQ on the subject.)

The long:

  I'd like to use GiNaC (http://www.ginac.de/) as part of a fairly
large modeling and simulation software project I'm working on as an
undergrad at Vanderbilt University.  I found it and installed it on my
Linux box (I only use Windows for work) and it does everything I need
it to do - and even better, it seems that someone has compiled it on
Windows as well!  (http://theor.jinr.ru/~varg/web/proj/ginac/woe32/)
Unfortunately, the DLL's contained within were compiled using ming,
and I'm stuck using the wretched compiler known as MSVC2005.  Because
I don't have the .def files mentioned in the tutorial, I've tried to
create them using dlltool and create the MSVC libraries that way -
unfortunately, depending on what command line options I use, it is
either read in as corrupt or I get unresolved references.

An example of my last attempt to solve this problem:
dlltool libginac-1-4-0.dll -k -z ginac.def -mi386 -U --export-all-symbols
lib /def:ginac.def /machine:x86
cl test.cpp /I"C:\Program Files\GiNaC\include" /EHsc /linkginac.lib

Which returns
ginac.lib : fatal error LNK1127: library is corrupt

I've been pounding away at this problem literally for 2 solid 8-hour
days, and I have scoured the internet very intently for an answer.  I
would very much like to not have to compile GiNaC in MSVC - any help
at all would be much appreciated.

-Will Chappell
WTC

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Greg Chicares
On 2009-06-02 22:52Z, Will Chappell wrote:
> The short: How do I (if I can) use ming DLL's with Visual Studio?  (I
> have read the ming FAQ on the subject.)

Probably you can't in this case, because...

>   I'd like to use GiNaC (http://www.ginac.de/)

http://www.ginac.de/FAQ.html
| GiNaC is written in ANSI-C++

See:
  http://oldwiki.mingw.org/index.php/MixingCompilers?redirectfrom=MixObjects

> it seems that someone has compiled it on
> Windows as well!  (http://theor.jinr.ru/~varg/web/proj/ginac/woe32/)
> Unfortunately, the DLL's contained within were compiled using ming,
> and I'm stuck using the wretched compiler known as MSVC2005.

http://www.ginac.de/FAQ.html#willitrun
| And since GiNaC borrows its numerical functionality from the library
| CLN, it needs to be compiled with the compiler CLN was compiled with.
| And currently CLN can only be compiled with GCC. If you are proud of
| your nifty commercial compiler and don't like this answer [...]

I assume you've already thought of using MinGW for everything, but
aren't allowed to do that because of some "policy" imposed on you.
Perhaps the paragraph quoted above from the GiNaC FAQ will enable
you to challenge that policy. IMO that's your best option.

There are other "options":
 - try to build GiNaC with your old version of msvc
 - write a C wrapper for the C++ library
 - use the "COM" trick mentioned in the last paragraph of the
     MinGW wiki article cited above
but my suspicion is that they'll prove to be a black hole that'll
just suck down all your time to no good end.

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Marc Vaillant

On Wed, Jun 03, 2009 at 12:49:20AM +0000, Greg Chicares wrote:

> On 2009-06-02 22:52Z, Will Chappell wrote:
> | And since GiNaC borrows its numerical functionality from the library
> | CLN, it needs to be compiled with the compiler CLN was compiled with.
> | And currently CLN can only be compiled with GCC. If you are proud of
> | your nifty commercial compiler and don't like this answer [...]
>
> I assume you've already thought of using MinGW for everything, but
> aren't allowed to do that because of some "policy" imposed on you.
> Perhaps the paragraph quoted above from the GiNaC FAQ will enable
> you to challenge that policy. IMO that's your best option.
>
> There are other "options":
>  - try to build GiNaC with your old version of msvc
>  - write a C wrapper for the C++ library
>  - use the "COM" trick mentioned in the last paragraph of the
>      MinGW wiki article cited above
> but my suspicion is that they'll prove to be a black hole that'll
> just suck down all your time to no good end.

I second everything Greg has written.  To this end, the game you really
have to play is figuring out how to structure your app so that the
interfaces that need to be accessed across compilers can either be C or
C++ that follows the COM ABI compatibility that Greg has mentioned
(direct link here http://aegisknight.org/cppinterface.html).  That might
mean building enough of your app in mingw so that what you need to
access from msvc can be just a couple classes in a mingw DLL that follow
ABI compatibility.  Or conversely, wrapping what you need from msvc in
ABI compatible classes, so that you can build your app in mingw.  

Good luck,
Marc

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Will Chappell
In reply to this post by Will Chappell
Thanks for the response, Greg.  If what you say is true (and I'm inclined to believe it is) I have another alternative to offer, which is probably most similar to the C-wrapper suggestion but less painful.
What if I were to write all of the code that uses GiNaC on windows in such a way that it can be compiled with mingw32 but is still linkable from msvc?  I guess it'd look something like this:

main_project (msvc) -> my_code_using_ginac (mingw32) -> ginac_precompiled_libraries (mingw32)


This way the precompiled insane DLL's from GiNaC and CLN don't have to be called directly from msvc - they can instead be called from a tamer, extern "C" interface that I provide to my code that uses GiNaC underneath.  This way, I avoid wrapping the entire interface of GiNaC and CLN - I can write code that uses them how I was planning on using them and wrap my sparse little interface in C.  Does this sound feasible?  I'm guessing that if I want to take this approach, I should probably do some reading into this link you referenced:

| http://aegisknight.org/cppinterface.html

If this approach is feasible, what other information do I need to know?  I may just go and test now using some dummy functions to see if this will work.  (Best of all, this means I can write code in Linux land, and avoid msvc almost entirely!)
Let me know if this is not being clear enough, I tend to skip details when I have crazy ideas that might just work.  I'll post my little interface test when I write it - hopefully that will clarify any questions.  If it is feasible, I'd certainly be willing to write a tutorial on it or something to give back for all the help!

(Sorry if this reply doesn't make it to the original thread!  Most mailing lists I reply to I don't get in digest mode, but I signed up for digest mode here, and I'm not quite sure how to reply to an email in it and make it into the same thread.  I hope that using the same subject will be enough.  Please educate me if it is not.)

Thanks,
Will Chappell
WTC

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Marc Vaillant
On Wed, Jun 03, 2009 at 11:32:59AM -0500, Will Chappell wrote:
> Thanks for the response, Greg.  If what you say is true (and I'm inclined to
> believe it is) I have another alternative to offer, which is probably most
> similar to the C-wrapper suggestion but less painful.
> What if I were to write all of the code that uses GiNaC on windows in such a
> way that it can be compiled with mingw32 but is still linkable from msvc?  I
> guess it'd look something like this:
>
> main_project (msvc) -> my_code_using_ginac (mingw32) ->
> ginac_precompiled_libraries (mingw32)

Will, this is what I suggested in my response this morning which you
might have missed.  This will work.  Again the game is to structure your
code so that you only need minimal interfaces for bridging across
compilers.  

>
>
> This way the precompiled insane DLL's from GiNaC and CLN don't have to be
> called directly from msvc - they can instead be called from a tamer, extern "C"
> interface that I provide to my code that uses GiNaC underneath.  This way, I
> avoid wrapping the entire interface of GiNaC and CLN - I can write code that
> uses them how I was planning on using them and wrap my sparse little interface
> in C.  Does this sound feasible?  I'm guessing that if I want to take this
> approach, I should probably do some reading into this link you referenced:
>
> | http://aegisknight.org/cppinterface.html

>
> If this approach is feasible, what other information do I need to know?  

Basically, everything you need to know is really covered in that
article.  One thing you need to be careful of is to keep your
allocations/deallocation on the same "side of the fence" (there is a
note about this in the article in the summary at the bottom).    I.e.
don't alloc on one side (say dll) but dealloc on the other (say app).  

Marc

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Will Chappell
Marc Vaillant <vaillant@...> writes:

>
> On Wed, Jun 03, 2009 at 11:32:59AM -0500, Will Chappell wrote:
> > Thanks for the response, Greg.  If what you say is true (and I'm inclined to
> > believe it is) I have another alternative to offer, which is probably most
> > similar to the C-wrapper suggestion but less painful.
> > What if I were to write all of the code that uses GiNaC on windows in such a
> > way that it can be compiled with mingw32 but is still linkable from msvc?  I
> > guess it'd look something like this:
> >
> > main_project (msvc) -> my_code_using_ginac (mingw32) ->
> > ginac_precompiled_libraries (mingw32)
>
> Will, this is what I suggested in my response this morning which you
> might have missed.  This will work.  Again the game is to structure your
> code so that you only need minimal interfaces for bridging across
> compilers.  

> > Does this sound feasible?  I'm guessing that if I want to take this
> > approach, I should probably do some reading into this link you referenced:
> >
> > | http://aegisknight.org/cppinterface.html
>
> >
> > If this approach is feasible, what other information do I need to know?  
>
> Basically, everything you need to know is really covered in that
> article.  One thing you need to be careful of is to keep your
> allocations/deallocation on the same "side of the fence" (there is a
> note about this in the article in the summary at the bottom).    I.e.
> don't alloc on one side (say dll) but dealloc on the other (say app).  


Alright, so just a little bit more help and I should me on my merry way - thanks
a lot so far.  I'm trying to follow the instructions given here -
| http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs

I have three files, named in the example, but in C++ - testdll.h, testdll.cpp,
and testmain.cpp.

_____________
testdll.h
_____________

#include <iostream>
extern "C" void print_stuff (void);

_____________
testdll.cpp
_____________

#include "testdll.h"
void print_stuff (void) {
  std::cout << "Hi." << std::endl;
}

_____________
testmain.cpp
_____________

int main () {
  print_stuff();
  return 0;
  }
_____________

I'm compiling with this command (yes, this is under Cygwin.  I'm under the
impression that this should be fine as long as I specify -mno-cygwin, please let
me know if this is a problem.)

g++ -shared -mno-cygwin -o testdll.dll testdll.cpp -Wl,--output-def,testdll.de
f,--out-implib,libtestdll.a

I'm then making the .lib with this command.

lib /machine:x86 /def:testdll.def

Finally, I try to compile with cl.

cl testmain.cpp testdll.lib

Which returns this:
testmain.cpp
testmain.cpp(3) : error C3861: 'print_stuff': identifier not found

Where am I screwing up?  Again, thank you so much for the help and guidance.

Will Chappell
WTC


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Tuomo Latto
Will Chappell wrote:
> testmain.cpp
> _____________
>
> int main () {
>   print_stuff();
>   return 0;
>   }
> _____________
>
[...]
> Where am I screwing up?  Again, thank you so much for the help and guidance.

You need to include the header in testmain.cpp...


FWIW, I would've tried compiling the library on MSVC first.
http://www.ginac.de/pipermail/cln-list/2009-April/000505.html
The files mentioned seem to be there if you check out an older
revision of the directory.
Of course, the licensing issues shouldn't be taken lightly.
Although, if I had to guess, the issue they addressed was
probably someone ending up compiling GPL'd code (octave, at least)
with MSVC linking it to non-OS MSVC libraries (the source code
of which they would then be required to distribute, which they
obviously can not do). This is obviously moot if you're not
planning on distributing the binaries.


--
Tuomo

... I don't have to take this abuse from you - I've got hundreds of people
    dying to abuse me.     -- Bill Murray as Peter Venkman in Ghostbusters


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Will Chappell



FWIW, I would've tried compiling the library on MSVC first.
http://www.ginac.de/pipermail/cln-list/2009-April/000505.html
The files mentioned seem to be there if you check out an older
revision of the directory.
Of course, the licensing issues shouldn't be taken lightly.
Although, if I had to guess, the issue they addressed was
probably someone ending up compiling GPL'd code (octave, at least)
with MSVC linking it to non-OS MSVC libraries (the source code
of which they would then be required to distribute, which they
obviously can not do). This is obviously moot if you're not
planning on distributing the binaries.


--
Tuomo

Tuomo, that's fantastic!  I'll get to work playing this right away.  As for the licensing issues - I think that most systems that will be using this system will already have msvc installed, rendering the redistribution of msvc DLL's moot.  And if they don't, I don't think we'd have a problem with requiring people to go and install them themselves - it does violate the spirit of the GPL, and I'd rather not, but my employer has more say over this than I do.  The other part of the licensing issue for this project is that it is under a GPL incompatible license at the moment - I'm hoping that my advisor will simply relicense the tool under the GPL and use this library when it becomes an issue, rather than finding some other, kludgier solution.  Right now it seems that the goal of the current license is more concerned with getting recognition and keeping track of who is using the tool than hiding the code base - I feel like they would choose the GPL in this case over their current license if an argument can be made that GiNaC makes the current code problems solvable.

Thanks a lot for the help,

-Will Chappell
WTC


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Greg Chicares
On 2009-06-04 21:28Z, Will Chappell wrote:
[...as Tuomo says:]

>> Of course, the licensing issues shouldn't be taken lightly.
>
> Tuomo, that's fantastic!  I'll get to work playing this right away.  As for
> the licensing issues - I think that most systems that will be using this
> system will already have msvc installed, rendering the redistribution of
> msvc DLL's moot.  And if they don't, I don't think we'd have a problem with
> requiring people to go and install them themselves - it does violate the
> spirit of the GPL, and I'd rather not, but my employer has more say over
> this than I do.  The other part of the licensing issue for this project is
> that it is under a GPL incompatible license at the moment

I fear your employer may be taking the licensing issues lightly.
AIUI, you want to link to ginac, which uses the GPL:
  http://www.ginac.de/FAQ.html#otherlicense
Some potential issues are discussed here:
  http://www.gnu.org/licenses/gpl-faq.html
Requiring users to purchase msvc might solve some problem with
the ms EULA, yet not with the GPL.

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Will Chappell
[...Greg]
>
> I fear your employer may be taking the licensing issues lightly.
> AIUI, you want to link to ginac, which uses the GPL:
>  http://www.ginac.de/FAQ.html#otherlicense
> Some potential issues are discussed here:
>  http://www.gnu.org/licenses/gpl-faq.html
> Requiring users to purchase msvc might solve some problem with
> the ms EULA, yet not with the GPL.

>From the threads posted earlier containing the Octave information -

________________
  - Distribute the the MSVC++ runtime libraries in a separate installer
    (then it's mere "aggregation" in the terms of the GPL), or

  - Arrange for the installer to pop up a browser window to the
    Microsoft VC++ redistributables download page.

The last two options are still not following the spirit of the GPL
(because they encourage the installation of closed-source libraries),
but legally not a GPL violation.
________________

I meant something more like the second option here - the installation
process for the tool is already fairly involved, adding such a step
should be trivial.

-Will Chappell
WTC

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Tuomo Latto
Will Chappell wrote:

> [...Greg]
>> I fear your employer may be taking the licensing issues lightly.
>> AIUI, you want to link to ginac, which uses the GPL:
>>  http://www.ginac.de/FAQ.html#otherlicense
>> Some potential issues are discussed here:
>>  http://www.gnu.org/licenses/gpl-faq.html
>> Requiring users to purchase msvc might solve some problem with
>> the ms EULA, yet not with the GPL.
>
>>From the threads posted earlier containing the Octave information -
>
> ________________
>   - Distribute the the MSVC++ runtime libraries in a separate installer
>     (then it's mere "aggregation" in the terms of the GPL), or
>
>   - Arrange for the installer to pop up a browser window to the
>     Microsoft VC++ redistributables download page.
>
> The last two options are still not following the spirit of the GPL
> (because they encourage the installation of closed-source libraries),
> but legally not a GPL violation.
> ________________
>
> I meant something more like the second option here - the installation
> process for the tool is already fairly involved, adding such a step
> should be trivial.

It's not an aggregation, which deals with separate program.
You're linking against the libraries, so they are a program
component.

It doesn't matter how you provide the redistributables. You're
still *linking* to them and I don't think they are "operating
system libraries". (Ginac uses GPLv2)
If you link your program only against libraries found in
%SystemRoot%\system32 after a fresh install (+maybe full
update), the incompatibility problem goes away.
(You will still be required to release the source, though,
since ginac is GPL.)

In GPLv3, the incompatibility doesn't exist as the definition
of system libraries essentially covers all run-time libraries.


Aggregation:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

System libraries exception, section 3.c and 1:
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section3
http://www.gnu.org/licenses/gpl-3.0.html#section1


--
Tuomo

... [Learning English by watching the A-Team and ST:TNG]
    You racing around in a Ford Mustang Shelby, until you eventually
    crash into some poor guy. Getting out, looking down at the
    bleeding corps saying. "I pity the fool".
    Then hailing a cab, getting in and saying "Engage"
    cabby: "man, your bleeding. Want me to get you to a hospital?"
    you: "Make it so"      -- ChaosDMNS, http://ars.userfriendly.org/
                               news/read.cgi?id=1208466459&tid=8427


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Marc Vaillant
In reply to this post by Will Chappell
On Thu, Jun 04, 2009 at 04:28:17PM -0500, Will Chappell wrote:

>
>
>
>     FWIW, I would've tried compiling the library on MSVC first.
>     http://www.ginac.de/pipermail/cln-list/2009-April/000505.html
>     The files mentioned seem to be there if you check out an older
>     revision of the directory.
>     Of course, the licensing issues shouldn't be taken lightly.
>     Although, if I had to guess, the issue they addressed was
>     probably someone ending up compiling GPL'd code (octave, at least)
>     with MSVC linking it to non-OS MSVC libraries (the source code
>     of which they would then be required to distribute, which they
>     obviously can not do). This is obviously moot if you're not
>     planning on distributing the binaries.
>
>
>     --
>     Tuomo
>
>
> Tuomo, that's fantastic!  I'll get to work playing this right away.  As for the
> licensing issues - I think that most systems that will be using this system
> will already have msvc installed, rendering the redistribution of msvc DLL's
> moot.  And if they don't, I don't think we'd have a problem with requiring
> people to go and install them themselves - it does violate the spirit of the
> GPL, and I'd rather not, but my employer has more say over this than I do.  The
> other part of the licensing issue for this project is that it is under a GPL
> incompatible license at the moment - I'm hoping that my advisor will simply
> relicense the tool under the GPL and use this library when it becomes an issue,
> rather than finding some other, kludgier solution.  

Will, you mentioned that this library has everything you need and more.
What is it that you really *need*?  If it's a linear algebra package
that you need (i.e. more matlab type things rather than symbolic Maple
stuff), then there are some very good options.  Forgive me if I'm
spouting information you already know.  BLAS/LAPACK--particularly Intel's
MKL implementation--has extremely high performance when it comes to lin
alg operations.  I'm referring to huge performance enhancements, not
incremental.  An elegant C++ package that provides BLAS type
functionality is Boost::ublas, however it is not nearly as efficient as
a real BLAS/LAPACK implementation.  Another is Blitz++.  

> Right now it seems that the goal of the current license is more
> concerned with getting recognition and keeping track of who is using
> the tool than hiding the code base - I feel like they would choose the
> GPL in this case over their current license if an argument can be made
> that GiNaC makes the current code problems solvable.

What are the current code problems?


------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: Using a mingw .dll with MSVC

Will Chappell
> Will, you mentioned that this library has everything you need and more.
> What is it that you really *need*?  If it's a linear algebra package
> that you need (i.e. more matlab type things rather than symbolic Maple
> stuff), then there are some very good options.  Forgive me if I'm
> spouting information you already know.  BLAS/LAPACK--particularly Intel's
> MKL implementation--has extremely high performance when it comes to lin
> alg operations.  I'm referring to huge performance enhancements, not
> incremental.  An elegant C++ package that provides BLAS type
> functionality is Boost::ublas, however it is not nearly as efficient as
> a real BLAS/LAPACK implementation.  Another is Blitz++.
>

> What are the current code problems?

The codebase I'm working with (actually, defacto rewriting from
scratch) deals with at least two equivalent abstract representations
of physical systems - bond graphs and block diagrams.  They're
actually pretty fascinating once you get past the initial headache of
trying to understand how they work.  Anyway, our code is ultimately
supposed to take in a bond graph or block diagram and simulate the
system, allowing engineers to find faults in their systems.  In order
to do that, we need to be able to solve algebraic loops to produce
equations, deal with a wide variety of input functions, and perform
fast, accurate, and precise calculations.  The ability to solve
algebraic loops is the biggest concern at the moment - the fact that
GiNaC and CLN solve the other two problems is just icing on the cake,
so to speak.  So, unfortunately, we need symbolic manipulation and
floating point calculations, and not linear algebra.

My goal now is two-fold -
1. Convince my adviser into GPL-ing the code base.
2. See if I can get GiNaC under the GPLv3 instead of the GPLv2, as per
what Tuomo pointed out:

> In GPLv3, the incompatibility doesn't exist as the definition
> of system libraries essentially covers all run-time libraries.

I hope they'd be receptive to such a thing, as I'm not trying to get a
proprietary exception - I'm just trying to get a different version of
the GPL.

I'm not sure how well my adviser will take to GPL-ing the codebase,
but I'm definitely going to try - the other options besides GiNaC are
rather unsavory, to say the least.  Either we'd have to figure out how
to solve algebraic loops for arbitrarily complex equations on our own,
which shows every sign of being a herculean task, or use a library
from another language, which would involve external calls and really
hamper the speed goal of the rewrite.  As long as I put it in terms of
the alternatives I think I'll have a chance at convincing him.

-Will Chappell
WTC

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) Thread hijacking
3) HTML/MIME encoded mail
4) Improper quoting
5) Improper trimming
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users