The part of interest is the functions you want exported from the Go program:
1 0 000813C0 RVExtension 2 1 00081360 RVExtensionArgs 3 2 00081310 RVExtensionVersion This article, http://www.mingw.org/wiki/sampledll, in section 'Building and using a DLL without the dllexport/dllimport attibutes' suggests the following approach: If you pass the --no-undefined and --enable-runtime-pseudo-reloc options to the linker, you don't have to add dllimport or dllexport attributes to the source code that the DLL is made with ; all functions are imported/exported automatically by default, just like in unices. Can you please try putting the following cgo directive for the linker in your Go file: // #cgo LDFLAGS: --no-undefined --enable-runtime-pseudo-reloc If you then rebuild your dll and see if the definition of your exported functions changes to _fn_name@arg_size in the output of dumpbin. You can use 'findstr' to filter the output of dumpbin based on a search pattern like so: dumpbin.exe /EXPORTS slib.dll | findstr "RVExtension" On Mon, Jun 24, 2019 at 7:35 PM nicolas_boiteux via golang-nuts <golang-nuts@googlegroups.com> wrote: > > Hello Alexander > > you can find the dump at this place: > https://pastebin.com/cg33nktu > > Le lundi 24 juin 2019 13:00:49 UTC+2, Alexander Kapshuk a écrit : >> >> Or was this it? >> >> #ifdef __cplusplus >> extern "C" { >> #endif >> extern void _RVExtensionVersion(char* p0, size_t p1); >> extern void _RVExtensionArgs(char* p0, size_t p1, char* p2, char** p3, int >> p4); >> extern void _RVExtension(char* p0, size_t p1, char* p2); >> #ifdef __cplusplus >> } >> #endif >> >> The 32-bit exports listed here, >> https://community.bistudio.com/wiki/Extensions, are most likely what >> is listed in the module-definition file ending in .def. >> Can you please try using the following declaration: >> //export RVExtension >> func RVExtension(output *C.char, outputsize C.size_t, input *C.char) {...} >> >> Compile your dll and post the output of dumpbin.exe /EXPORTS >> /path/to/slib.dll showing the listing of your exported symbols? >> >> On Mon, Jun 24, 2019 at 11:41 AM Alexander Kapshuk >> <alexande...@gmail.com> wrote: >> > >> > If I understand it correctly, cgo should have generated a >> > _cgo_export.h header with a declaration for your exported function. >> > Can you please post the generated declaration? >> > >> > On Mon, Jun 24, 2019 at 12:47 AM <ono...@gmail.com> wrote: >> > > >> > > We are trying to make the x32 version of the extension, as shown in the >> > > link below. >> > > https://community.bistudio.com/wiki/Extensions#C.2FC.2B.2B >> > > >> > > How we see, for x64 we must use entry points >> > > >> > > RVExtension >> > > RVExtensionArgs >> > > RVExtensionVersion >> > > >> > > >> > > but for x32 >> > > >> > > _RVExtension@12 >> > > _RVExtensionArgs@20 >> > > _RVExtensionVersion@8 >> > > >> > > >> > > It is very hard for me to explain to you exactly what we need, because I >> > > am new to this language, and C doesn’t know at all. I really hope that >> > > you understand what I mean. >> > > >> > > воскресенье, 23 июня 2019 г., 22:20:53 UTC+3 пользователь Kurtis Rader >> > > написал: >> > >> >> > >> On Sun, Jun 23, 2019 at 4:49 AM nicolas_boiteux via golang-nuts >> > >> <golan...@googlegroups.com> wrote: >> > >>> >> > >>> I need some assistance to export a GO dll function to a C program. >> > >>> >> > >>> The C program (wich i m not the author) required to call a function >> > >>> with this name: _RVExtension@12 >> > >> >> > >> >> > >> That is not a valid symbol (i.e., function name) in either C or Go. In >> > >> other words the following C is invalid: >> > >> >> > >> extern int _RVExtension@12(); >> > >> int main() { >> > >> _RVExtension@12(); >> > >> } >> > >> >> > >> Your question has nothing to do with Go or C as such. What does the >> > >> "@12" represent? Is it an API version number? In any event your >> > >> question is really about a specific build toolchain on a specific >> > >> platform. And you didn't even bother to tell us what platform you are >> > >> using. I'm guessing MS Windows but we shouldn't have to make such >> > >> guesses. >> > >> >> > >> -- >> > >> Kurtis Rader >> > >> Caretaker of the exceptional canines Junior and Hank >> > > >> > > -- >> > > You received this message because you are subscribed to the Google >> > > Groups "golang-nuts" group. >> > > To unsubscribe from this group and stop receiving emails from it, send >> > > an email to golan...@googlegroups.com. >> > > To view this discussion on the web visit >> > > https://groups.google.com/d/msgid/golang-nuts/ec18ff38-d70b-41ef-b7b4-fb243f407e1c%40googlegroups.com. >> > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/0e90774a-3814-4d71-b752-8cd399cb26e3%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJ1xhMVyyo51hjaBbJsFTZFH%2BygQESJ940ismLDpQzu7RdZ6_w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
