Add annotations for exporting generated functions from a Windows DLL #13726

dawidcha · 2023-08-24T15:00:37Z

I'm currently engaged in some work with gRPC aiming at merging a PR which permits gRPC to be built as a dynamic library under Windows (i.e. a DLL). here. gRPC makes use of μpb and needs to expose symbols generated by it from a DLL. That requires that the functions marked as extern be annotated with '__declspec(dllexport)' when compiled and '__declspec(dllimport)' when consumed.

For the protoc compiler, this is achieved by prefixing the file output location on the command line with dllexport_decl=MY_EXPORT_MACRO, and then defining MY_EXPORT_MACRO as either __declspec(dllimport) or __declspec(dllexport); or empty string, as appropriate, but this feature doesn't appear to be available in μpb.

Can something similar be added?

github-actions · 2023-11-28T10:01:57Z

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

h-vetinari · 2023-11-28T10:12:38Z

Not stale.

github-actions · 2024-02-27T10:02:10Z

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

h-vetinari · 2024-02-27T10:21:25Z

This is not stale, and there's an on open PR for this as well, at least in the context of upb (for now): #14981

github-actions · 2024-05-28T10:02:08Z

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

h-vetinari · 2024-06-08T00:12:53Z

Not stale, and has a new PR now too: #17079

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a FUTURE_COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a PiperOrigin-RevId: 641996346

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a FUTURE_COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a PiperOrigin-RevId: 641996346

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a FUTURE_COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a PiperOrigin-RevId: 641996346

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a FUTURE_COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a PiperOrigin-RevId: 641996346

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a FUTURE_COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 523b92a PiperOrigin-RevId: 641996346

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 34927b1 FUTURE_COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 34927b1 PiperOrigin-RevId: 642315126

@dawidcha

…7079) Picking up #14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of #14230 > > Fixes: #14255 Towards #13726 Closes #14981 Closes #17079 COPYBARA_INTEGRATE_REVIEW=#17079 from h-vetinari:add_dll_tags 34927b1 PiperOrigin-RevId: 642622258

@dawidcha

…otocolbuffers#17079) Picking up protocolbuffers#14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of protocolbuffers#14230 > > Fixes: protocolbuffers#14255 Towards protocolbuffers#13726 Closes protocolbuffers#14981 Closes protocolbuffers#17079 COPYBARA_INTEGRATE_REVIEW=protocolbuffers#17079 from h-vetinari:add_dll_tags 34927b1 PiperOrigin-RevId: 642622258

@dawidcha

…otocolbuffers#17079) Picking up protocolbuffers#14981 from @dawidcha after several months of radio silence. Quoting the OP of that PR: > I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](grpc/grpc#34345) are pending. > > The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport). > > This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library. > > This is a continuation of protocolbuffers#14230 > > Fixes: protocolbuffers#14255 Towards protocolbuffers#13726 Closes protocolbuffers#14981 Closes protocolbuffers#17079 COPYBARA_INTEGRATE_REVIEW=protocolbuffers#17079 from h-vetinari:add_dll_tags 34927b1 PiperOrigin-RevId: 642622258

github-actions · 2024-09-06T10:02:17Z

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

h-vetinari · 2024-09-06T14:46:02Z

Not stale

github-actions · 2024-12-06T10:02:13Z

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.

h-vetinari · 2024-12-07T08:20:32Z

Not stale (c.f. also #19422)

acozzette transferred this issue from protocolbuffers/upb Aug 29, 2023

github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Nov 28, 2023

github-actions bot removed the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Nov 29, 2023

github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Feb 27, 2024

github-actions bot removed the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Feb 28, 2024

github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label May 28, 2024

h-vetinari mentioned this issue Jun 8, 2024

Adding DLL export/import tags to generated public upb API (redux) #17079

Closed

github-actions bot removed the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Jun 8, 2024

copybara-service bot mentioned this issue Jun 10, 2024

Adding DLL export/import tags to generated public upb API (redux) (#17079) #17090

Closed

copybara-service bot mentioned this issue Jun 11, 2024

Adding DLL export/import tags to generated public upb API (redux) (#17079) #17105

Merged

github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Sep 6, 2024

github-actions bot removed the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Sep 7, 2024

h-vetinari mentioned this issue Sep 25, 2024

Figure out upb-situation vs. grpc; do not remove deprecated C++-backend until then #12927

Open

h-vetinari mentioned this issue Nov 27, 2024

ENH: automatically create macro-definition for EXPORT_MACRO FOO in generated files #19422

Open

github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Dec 6, 2024

github-actions bot removed the inactive Denotes the issue/PR has not seen activity in the last 90 days. label Dec 7, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add annotations for exporting generated functions from a Windows DLL #13726

Add annotations for exporting generated functions from a Windows DLL #13726

dawidcha commented Aug 24, 2023

github-actions bot commented Nov 28, 2023

h-vetinari commented Nov 28, 2023

github-actions bot commented Feb 27, 2024

h-vetinari commented Feb 27, 2024

github-actions bot commented May 28, 2024

h-vetinari commented Jun 8, 2024

github-actions bot commented Sep 6, 2024

h-vetinari commented Sep 6, 2024

github-actions bot commented Dec 6, 2024

h-vetinari commented Dec 7, 2024

Add annotations for exporting generated functions from a Windows DLL #13726

Add annotations for exporting generated functions from a Windows DLL #13726

Comments

dawidcha commented Aug 24, 2023

github-actions bot commented Nov 28, 2023

h-vetinari commented Nov 28, 2023

github-actions bot commented Feb 27, 2024

h-vetinari commented Feb 27, 2024

github-actions bot commented May 28, 2024

h-vetinari commented Jun 8, 2024

github-actions bot commented Sep 6, 2024

h-vetinari commented Sep 6, 2024

github-actions bot commented Dec 6, 2024

h-vetinari commented Dec 7, 2024