|
From: | Marco atzeri |
Subject: | Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows |
Date: | Fri, 17 Jun 2011 17:03:23 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 |
On 6/17/2011 4:14 PM, Charles Wilson wrote:
On 6/17/2011 3:46 AM, Marco atzeri wrote:on cygwin "lt_cv_deplibs_check_method=pass_all" is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building.It's not about "system capabilities" in this case. It's about the fact that this -- creating a shared library by linking against existing static libraries -- is a really bad idea. If any of those static libs (a) exports a data item, and (b) is used by more than one DLL in your stack, then you'll end up with two different copies of the data item, and one DLL will use the first copy while the other DLL will use the second copy.
Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. I know that octave on cygwin is an extreme case due its number of dependencies, but it is not the only case. Of course my knowledge of libtool is limited and eventually there is another way but I never found it.
-- Chuck
Marco
[Prev in Thread] | Current Thread | [Next in Thread] |