If you want to test, you can retrieve the content of this git : https://github.com/code34/armago_x64/tree/32bits
build the 32 bits dll in the same directory with the name : armago.dll after this you only have to called : callextension.exe ./test_script.sqf if the dll doesn't works as expected it will return a method unrecognized, if not return the string declared in the test_script.sqf Le mardi 25 juin 2019 18:53:27 UTC+2, nobody nobodye a écrit : > > Conflicting declaration for RVExtension declaration :( and the -ldflags > doesn't shown the same parameters. > > > Le mardi 25 juin 2019 13:27:14 UTC+2, Alexander Kapshuk a écrit : >> >> Tried that. Still no luck. Hm. >> >> I'm not sure how you've been building your DLL, but if you're >> including the _cgo_export.h in your .c file which is then >> compiled/linked into a DLL, perhaps you could manually try changing >> this line: >> extern void RVExtension(char* p0, size_t p1, char* p2); >> >> into what is suggested here, >> https://community.bistudio.com/wiki/Extensions: >> extern __attribute__((dllexport)) void RVExtension(char *output, int >> outputSize, const char *function); >> >> And see if that does it. >> Other than that, I'm afraid I don't have any more ideas for you to try. >> Sorry. >> >> On Tue, Jun 25, 2019 at 10:07 AM Alexander Kapshuk >> <alexande...@gmail.com> wrote: >> > >> > Wander if specifying those linker flags via the '-ldflags' command >> > line option would make a difference: >> > go help build: >> > -ldflags '[pattern=]arg list' >> > arguments to pass on each go tool link invocation. >> > >> > On Tue, Jun 25, 2019 at 9:16 AM nicolas_boiteux via golang-nuts >> > <golan...@googlegroups.com> wrote: >> > > >> > > it tried to also allow those flags by setting the env variablee >> ldflag allow but it seems to have no effect. >> > > >> > > Le lundi 24 juin 2019 21:15:34 UTC+2, nobody nobodye a écrit : >> > >> >> > >> 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> 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. >> > >>> > 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 golan...@googlegroups.com. >> > > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/42f99da7-1f92-4826-90a3-b785fdc3d071%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/dc63308e-3ad5-4f9f-8bc0-6092c0a9f324%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
