search for: dllimported

...a warning (similar to clang's current behavior) /* test1.c */ inline __declspec(dllimport) void foo(); inline void foo(); inline void foo() { } void foo_user() { foo(); } /* end of file */ But for the following two cases, GCC produces both an out-of-line definition and also a reference to an dllimported symbol foo with no diagnostics. It seems wrong, unless there is some problem with my build process. /* test2.c */ inline void foo(); __declspec(dllimport) void foo(); inline void foo() { } void foo_user() { foo(); } /* end of file */ /* test3.c */ inline void foo(); __declspec(dllimport) void foo...

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 --------------

...discarded. > I think dllimport inline functions are more closely related to the available_externally > linkage than linkonce_odr; no COMDAT is involved and no .linkonce discard directive > is needed. I would name it dllimport_inline or something similar. Hm, I don't think so, because dllimported inline functions must never be instantiated, or else you get duplicated symbols. They are only allowed to be expanded. At the moment I solve this by checking for definitions during codegen (this means they survived the inliner) and dropping their body. > While it makes sense to mimic MSVC b...

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

...ke your approach, I wonder if it makes sense to rename the existing linkage type to something different, e.g., OldLinkage to NewLinkage, so that future patches using hasOldLinkage() will have to check their codes to make sure they work with the new semantics. > Hm, I don't think so, because dllimported inline functions must never be > instantiated, or else you get duplicated symbols. They are only allowed to be > expanded. At the moment I solve this by checking for definitions during > codegen (this means they survived the inliner) and dropping their body. I agree. Hmm that is exactly w...

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