it seems that flags --no-undefined --enable-runtime-pseudo-reloc are invalid flags :(
/* #cgo LDFLAGS: --no-undefined --enable-runtime-pseudo-reloc #include <stdlib.h> #include <stdio.h> #include <string.h> */ import "C" Le lundi 24 juin 2019 18:58:22 UTC+2, Alexander Kapshuk a écrit : > > 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 > <golan...@googlegroups.com <javascript:>> 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 golan...@googlegroups.com <javascript:>. > > 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/b201a5c5-9c9f-40c9-af80-f4474aebd180%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
