Marvin, i just publish the last version of my files on git:
can you please check them, and say me if the declaration/definition are ok
? I m not familiar with this cross langage compilation context/
https://github.com/code34/armago_x64/tree/32bits
Le mercredi 26 juin 2019 20:10:55 UTC+2, Marvin
* nicolas_boiteux via golang-nuts [190626 13:19]:
> /*
> #include
> #include
> #include
> extern void __stdcall RVExtension(char *output, int outputSize, const char
> *function);
> */
>
> //export RVExtensionVersion
> func RVExtensionVersion(output *C.char, outputsize C.size_t) {
> result
/*
#include
#include
#include
extern void __stdcall RVExtension(char *output, int outputSize, const char
*function);
*/
//export RVExtensionVersion
func RVExtensionVersion(output *C.char, outputsize C.size_t) {
result := C.CString("Version 1.0")
defer C.free(unsafe.Pointer(result))
* nicolas_boiteux via golang-nuts [190626 12:15]:
> i have some news.
>
> With this kind of declaration
> extern void __fastcall RVExtension(char *output, int outputSize, const char
> *function){
> goRVExtension(output, outputSize, function);
> };
> as you can see in error message this tim
i have some news.
With this kind of declaration
extern void __fastcall RVExtension(char *output, int outputSize, const char
*function){
goRVExtension(output, outputSize, function);
};
// export goRVExtension
func goRVExtension(output *C.char, outputsize C.size_t, input *C.char) {
temp :
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019
--
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...@googlegr
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 i
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
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 i
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
wrote:
>
> it trie
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-unde
it seems that flags --no-undefined --enable-runtime-pseudo-reloc are
invalid flags :(
/*
#cgo LDFLAGS: --no-undefined --enable-runtime-pseudo-reloc
#include
#include
#include
*/
import "C"
Le lundi 24 juin 2019 18:58:22 UTC+2, Alexander Kapshuk a écrit :
>
> The part of interest is the func
The part of interest is the functions you want exported from the Go program:
10 000813C0 RVExtension
21 00081360 RVExtensionArgs
32 00081310 RVExtensionVersion
This article, http://www.mingw.org/wiki/sampledll, in section
'Building and using a DLL without the dllexport/dllimport attib
i don't know why it so much verbose perhaps i don't use the good
compilation flag .
Here another dump of a 32 bit dll extension with the same entry point but
coded with c# (for comparaison purpose)
Microsoft (R) COFF/PE Dumper Version 14.21.27702.2
Copyright (C) Microsoft Corporation. All righ
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 _RVExt
Ok. Thanks.
What's the output of dumpbin.exe /EXPORTS /path/to/slib.dll showing
the listing of your exported functions?
On Mon, Jun 24, 2019 at 2:37 PM wrote:
>
> /* Code generated by cmd/cgo; DO NOT EDIT. */
>
> /* package _/F_/Git/returnHWID-Arma */
>
>
> #line 1 "cgo-builtin-export-prolog"
>
>
/* Code generated by cmd/cgo; DO NOT EDIT. */
/* package _/F_/Git/returnHWID-Arma */
#line 1 "cgo-builtin-export-prolog"
#include /* for ptrdiff_t below */
#ifndef GO_CGO_EXPORT_PROLOGUE_H
#define GO_CGO_EXPORT_PROLOGUE_H
#ifndef GO_CGO_GOSTRING_TYPEDEF
typedef struct { const char *p; ptrdif
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 list
Hello Alexander,
from my understanding, we need to build a GO 32 bits DLL for a C software.
To load this DLL, the C software loads an entry point function called
_RVExtension@12 wich is a decorated/mangle C name/
It seems that cgo doesn't accept to export functions with '@' in name
composition
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 wrote:
>
> We are trying to make the x32 version of the extension, as shown in the link
>
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
- _RV
thanks you Marvin for this interesting article. You point the real problem
:)
Le dimanche 23 juin 2019 22:55:05 UTC+2, Marvin Renich a écrit :
>
> * nicolas_boiteux via golang-nuts >
> [190623 15:33]:
> > Precisly, i don't know what is this @12, and nobody can explain this :(
> > It's for a wi
remove the _ underscore.
> On Jun 23, 2019, at 2:20 PM, Kurtis Rader wrote:
>
>> On Sun, Jun 23, 2019 at 4:49 AM nicolas_boiteux via golang-nuts
>> 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
* nicolas_boiteux via golang-nuts [190623 15:33]:
> Precisly, i don't know what is this @12, and nobody can explain this :(
> It's for a windows build and the dll is load by arma game.
The leading '_' and trailing '@' followed by a number is the __stdcall
decoration for a C name in the produced
Hello Kurtis,
Precisly, i don't know what is this @12, and nobody can explain this :(
It's for a windows build and the dll is load by arma game.
more informations at this place:
https://community.bistudio.com/wiki/Extensions
in c#, i used this line for export 32 bits dll
[DllExport("_RVExtensi
On Sun, Jun 23, 2019 at 4:49 AM nicolas_boiteux via golang-nuts <
golang-nuts@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 val
Hello,
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
so, i simply declare my go function like this:
//export _RVExtension@12
func _RVExtension@12(output *C.char, outputsize
27 matches
Mail list logo
