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
<golang-nuts@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 golang-nuts+unsubscr...@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/CAJ1xhMXzHdHKswzjatA0xsmW%2BMtsJkcXJkT%3D9x7%2BFeVP7fJ9VQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
