search for: dllimports

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but

The following patch changes export.h so that the dllimport/dllexport attributes work with mingw/mingw-w64 and others: - changes _declspec keyword to __declspec: the former may not be defined by some toolchains. - changes the _MSC_VER condition to universally _WIN32: MSVC, as well as GCC supports this. Attached patch: declspec.diff Regards. -- O.S. -------------- next part --------------

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

After a long processing, I was able to create a version of a small C# class that was able to emulate the rproxy by P/Invoke. This is mostly to find a workaround a performance problem of the StatConnector. It's almost work but ... I have strange memory exception when I call the print function. The variable seems to not survive from one call to the other. As there is no debug symbol for

Hi - I wrapped R.dll up using somebody code online (see below). I am comparing R on .NET IPC with R(D)COM. I got it all working. Except, I realize that in my client code of the IPC remoting, if I call 'plot' function in R via EvaluateNoReturn, I don't seem to see any results on the R plot window (although the window pops up). Is there anything to do with the code of R.dll wrapper

On 5/24/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Ozkan Sezer <sezeroz at gmail.com> ?????(?) ? ????? ?????? Sat, 24 May 2014 > 10:16:15 +0400: > >> - changes the _MSC_VER condition to universally _WIN32: MSVC, as well >> as GCC supports this. > > MSYS/MinGW 4.8.3, 4.9.0 can't compile code from git after this patch: > > format.c:47:22: error:

hello guys this is my code for the C# wrapper. ================================= using System; using System.Runtime.InteropServices; using System.IO; namespace Speex { ///<summary> ///the following class is the win32 SPEEX API that retrieve ///methods and structures from the libspeex file ///</summary> public unsafe class Speex_win32 { #region Speex Constants //global speex

Hi, There is some additional work to do (close lsa handle), but the far the code below is working. Let me share it with you in case somebody will have the same need that me. br Vincent LE TOUX using Microsoft.Win32.SafeHandles; using System; using System.ComponentModel; using System.Diagnostics; using System.Net; using System.Runtime.InteropServices; using System.Security.Principal; namespace

Hi Nico, Thank you for your feedback. I'll try to answer your questions below. > What problems do you expect with another approach? I have a local > prototype that removes dllimport/export as linkage and uses function > attributes and an extension to globals. I decorate dllexported functions with > the Used attribute and it seems to work fine. This allows such functions to >

Hi there, I have searched what seems like everywhere and was unable to find a .NET wrapper so that I can use speex in VB. I did find a speex.NET.dll but this didn't seem to work on what I needed. I therefore decided I could just use DllImport within VB .NET and create my own unmanaged links to libspeex.dll. With the help of this partial c# code

Harry Sack wrote: > > but aren't they C++ headers en lib's? Not C++, C. > I have no idea how I can include a C++ > header in a C# project. > It this even possible? Yes. Google for "dllimport csharp". Erik -- ----------------------------------------------------------------- Erik de Castro Lopo -----------------------------------------------------------------

Hi SAITAMA Taro, I have been using speex-1.2beta1 dll in our voice application written with C#. In order to use Speex correctly firstly I advice to you examination speexenc and speexdec projects. I have used unsafe code and fixed statements in C#. I have added following method to library and I used that instead of speex_encoder_init simply. void *speex_encoder_init_new(int modeID) { const

?Hi all, Can someone tell me how to import functions from shared libraries and use them in LLVM assembly Regards, Dylan Borg +356 99214902 borgdylan at hotmail.com borgdylang at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101225/77e1182c/attachment.html>

Hi Dylan, If you have "import libraries", you may call them with general calling conversions. Without import libraries, for example; declare dllimport i32 @foo(i32) @quux = dllimport global i32 define i32 @bar() nounwind { %a = load i32* @quux %r = call i32 @foo(i32 %a) ret i32 %r } .globl _bar _bar: subl $4, %esp movl __imp__quux, %eax

I tried that approach a while ago and failed miserably. Marshalling the structs of structs in the flac lib turned out to be a nightmare (I don't pretend to be an expert, mind you...). I eventually switched to writing my own C# lib from scratch. Work is still under progress. It's no rocket science, I do this a G-job. It has definite limitations (no documentation, decodes only 16-bit files,

Hi All, I am trying to cross compile speex-1.1.12 to powerpc-405, i get a error after the make, speexec.lo error, please help me how to get rid of this error. On 2/9/07, speex-dev-request@xiph.org <speex-dev-request@xiph.org> wrote: > Send Speex-dev mailing list submissions to > speex-dev@xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit >

Ozkan Sezer wrote: > flac.exe built with mingw with or without the dllimport/dllexport patch > always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la > in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it > any more or any less dependent on any 'foreign' dlls: the patch doesn't > change the existent situation in that regard. If

On 5/25/14, lvqcl <lvqcl.mail at gmail.com> wrote: > Erik de Castro Lopo wrote: > >> Ozkan Sezer wrote: >> >>> My apologies, obviously sent an old testing patch. Correct one is >>> attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5, >>> binutils-2.20), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) >> >> lvqcl, >>

Erik de Castro Lopo wrote: > Ozkan Sezer wrote: > >> My apologies, obviously sent an old testing patch. Correct one is >> attached (declspec2.diff). Compilation tested using MinGW (gcc-3.4.5, >> binutils-2.20), and MinGW-w64 (gcc-4.5.4, binutils-2.21.90.) > > lvqcl, > > Can you please validate this new patch? It works, but only if i call ./configure without