On 07.03.2019 10:11, Пётр Байкалов wrote:
> How do I get the name of library which will be imported? For example, I
> have "libopencv_phase_unwrapping.dll.a" , how do I get
> "libopencv_phase_unwrapping320.dll" from it?
dlltool -I libopencv_phase_unwrapping.dll.a
signature.asc
Description: Open
Hello.
How do I get the name of library which will be imported? For example, I
have "libopencv_phase_unwrapping.dll.a" , how do I get
"libopencv_phase_unwrapping320.dll" from it? It is definitely happening
inside linker and it is not accessing the
"libopencv_phase_unwrapping320.dll" (I checked it)
In August of 2011[1] Microsoft announced deprecation of the Microsoft
OLE DB Provider for SQL Server. But in October of 2017 Microsoft had to
undeprecate[2] OLE DB data access technology releasing the ``Microsoft
OLE DB Driver for SQL Server'' known as ``msoledbsql''.
This commit adds the ``msol
Oops! I'm really sorry, I've messed up the patch... I'll resend it in a
few minutes. Sorry.
On March 7, 2019 9:25:22 AM Ruslan Garipov wrote:
In August of 2011[1] Microsoft announced deprecation of the Microsoft
OLE DB Provider for SQL Server. But in October of 2017 Microsoft had to
und
In August of 2011[1] Microsoft announced deprecation of the Microsoft
OLE DB Provider for SQL Server. But in October of 2017 Microsoft had to
undeprecate[2] OLE DB data access technology releasing the ``Microsoft
OLE DB Driver for SQL Server'' known as ``msoledbsql''.
This commit adds the ``msol
在 2019/3/7 上午5:11, Martin Storsjö 写道:
> On Wed, 6 Mar 2019, Jacek Caban wrote:
>
>>
>> It exists in msvcrt.dll that I checked (I think it's from win10). The
>> patch looks good to me.
>
> _mkgmtime64 appeared in msvcrt.dll in Vista, it's missing in XP.
>
> // Martin
I think it might be safer to
On Wed, 6 Mar 2019, Jacek Caban wrote:
On 3/6/19 3:53 PM, Liu Hao wrote:
在 2019/3/6 22:44, Jacek Caban 写道:
Looks good to me, but it needs msvcrt.def.in adjustment first.
_mkgmtime64 is not available on i386, but it should.
An additional patch has been attached.
But anyway, I think these co
Your experience matches mine: the Cygwin ldd utility does not work properly
with MinGW DLLs and prints a bunch of question marks. There is an ntldd
utility you can use instead. If it's not on your path already, I'm not
sure the best way to obtain it. I just use MSYS2, because it's basically a
fo
On 3/6/19 3:53 PM, Liu Hao wrote:
在 2019/3/6 22:44, Jacek Caban 写道:
Looks good to me, but it needs msvcrt.def.in adjustment first.
_mkgmtime64 is not available on i386, but it should.
An additional patch has been attached.
But anyway, I think these conditions existed for a reason. I can veri
在 2019/3/6 22:44, Jacek Caban 写道:
> Looks good to me, but it needs msvcrt.def.in adjustment first.
> _mkgmtime64 is not available on i386, but it should.
>
>
An additional patch has been attached.
But anyway, I think these conditions existed for a reason. I can verify
that they all exist on my W
On 3/6/19 3:33 PM, Liu Hao wrote:
在 2019/3/4 22:54, Jacek Caban 写道:
Hi Johannes,
On 3/3/19 2:48 PM, Johannes Pfau wrote:
When building GCC for msvcrt120, there's a undefined reference to
ctime. It needs to be defined as a wrapper for msvcrt120 as well.
The if condition is slightly complex, but
在 2019/3/4 22:54, Jacek Caban 写道:
> Hi Johannes,
>
> On 3/3/19 2:48 PM, Johannes Pfau wrote:
>> When building GCC for msvcrt120, there's a undefined reference to
>> ctime. It needs to be defined as a wrapper for msvcrt120 as well.
>> The if condition is slightly complex, but I do not know if I can
Hello,
We have some bigger Java applications running as fat clients on
Windows PC. These clients are using some Windows services, for example for
printing, through some DLL written in C++ many years ago and then only
compiled as 32-bit DLL. Moving forward to OpenJDK 1.8 with a 64-bit JRE
we now
13 matches
Mail list logo
