Re: [protobuf] Re: Windows Dll
Fixed in revision 286. On Fri, Dec 25, 2009 at 2:28 PM, Kenton Varda wrote: > Ah, yeah, I hadn't tested compiling as a DLL under MSVC yet. Thanks for > reminding me to fix this before the final release. 2.2.0 should work. > > > On Fri, Dec 25, 2009 at 1:27 AM, Soth wrote: > >> I`m using 2.3.0rc1. >> >> On 25 дек, 07:07, Kenton Varda wrote: >> > What version did you try this with? >> > >> > On Thu, Dec 24, 2009 at 3:38 PM, Soth wrote: >> > > Hi, >> > > I`ve tried to compile the protocol buffers library as a DLL in >> > > msvs2008 and it didn`t link. The problems are basically with incorrect >> > > export of functions/classes from the libprotobuf-lite and >> > > libprotobuf : >> > >> > > 1) StringSpaceUsedExcludingSelf undefined in lite, to solve moved >> > > definition from generated_message_reflection.h to repeated_field.cc >> > >> > > 2) bool DescriptorPoolExtensionFinder::Find(int number, ExtensionInfo* >> > > output) undefined in lite and i think it can be only solved by >> > > removing DescriptorPoolExtensionFinder class declaration from the >> > > extension_set.h and placing it in to a new file in libprotobuf >> > > extension_set_heavy.h or somewhere else in libprotobuf local headers. >> > >> > > On Dec 23, 3:51 am, Kenton Varda wrote: >> > > > If you link protobuf as a DLL: >> > >> > > > (1) You must link to the C runtime as a DLL, otherwise you'll end up >> with >> > > > two copies of the C runtime, which may mean two separate heaps, >> among >> > > other >> > > > things. >> > >> > > > (2) All components of your application which use protocol buffers >> must >> > > link >> > > > to the same C runtime as the protocol buffers DLL. This is true >> when >> > > static >> > > > linking as well, but sometimes people mistakenly think that it is >> not >> > > true >> > > > with DLLs. >> > >> > > > (3) All components of your application which use protocol buffers >> must >> > > use >> > > > the same version of protocol buffers. The DLL binary interface is >> not >> > > > compatible between two different versions. >> > >> > > > (4) You absolutely cannot place the protobuf DLL in a system shared >> > > > directory, because it may be incompatible with other apps which use >> a >> > > > different version of the DLL. The DLL has to stay in your >> application's >> > > own >> > > > directory. >> > >> > > > Given these constraints, there isn't much benefit to dynamic linking >> for >> > > > most people. Usually the advantage of using a DLL is that you can >> share >> > > it >> > > > between multiple programs, but that is unlikely to work well with >> > > protocol >> > > > buffers due to the interface version compatibility issues. >> > >> > > > Another typical reason to use DLLs is because you want to provide a >> > > "plugin" >> > > > system for your application. But if all your plugins link against >> > > > libprotobuf as a DLL, then they must all use the same version of >> protocol >> > > > buffers, which is a pretty serious limitation to any plugin system. >> A >> > > > better approach would be to statically link each plugin individually >> > > against >> > > > protocol buffers; this way, each plugin has its own embedded copy >> and >> > > > doesn't have to worry about version compatibility with other >> plugins. >> > > > However, if you do this, then you cannot pass protocol buffer >> objects >> > > > between plugins, since they might use different versions of the >> library. >> > > You >> > > > can, however, pass encoded messages between plugins -- the encoding >> > > format >> > > > is (obviously) compatible between versions. >> > >> > > > On Mon, Dec 21, 2009 at 5:21 PM, Soth wrote: >> > > > > Hi, >> > > > > in protobuf documentation it`s stated that static linking is >> preferred >> > > > > to dynamic because of different issues. I`d like to know what >> these >> > > > > issues are, what i shouldnt do with the protobuf if i link with it >> > > > > dynamically and how come that static linking is better. Thanks >> ahead. >> > >> > > > > -- >> > >> > > > > You received this message because you are subscribed to the Google >> > > Groups >> > > > > "Protocol Buffers" group. >> > > > > To post to this group, send email to proto...@googlegroups.com. >> > > > > To unsubscribe from this group, send email to >> > > > > protobuf+unsubscr...@googlegroups.com >> >> > >> > > >> > > > > . >> > > > > For more options, visit this group at >> > > > >http://groups.google.com/group/protobuf?hl=en.-Hide quoted text - >> > >> > > > - Show quoted text - >> > >> > > -- >> > >> > > You received this message because you are subscribed to the Google >> Groups >> > > "Protocol Buffers" group. >> > > To post to this group, send email to proto...@googlegroups.com. >> > > To unsubscribe from this group, send email to >> > > protobuf+unsubscr...@googlegroups.com >> >> > >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/protobuf?hl=en. >> >> -- >> >> You received this message beca
Re: [protobuf] Re: Windows Dll
Ah, yeah, I hadn't tested compiling as a DLL under MSVC yet. Thanks for reminding me to fix this before the final release. 2.2.0 should work. On Fri, Dec 25, 2009 at 1:27 AM, Soth wrote: > I`m using 2.3.0rc1. > > On 25 дек, 07:07, Kenton Varda wrote: > > What version did you try this with? > > > > On Thu, Dec 24, 2009 at 3:38 PM, Soth wrote: > > > Hi, > > > I`ve tried to compile the protocol buffers library as a DLL in > > > msvs2008 and it didn`t link. The problems are basically with incorrect > > > export of functions/classes from the libprotobuf-lite and > > > libprotobuf : > > > > > 1) StringSpaceUsedExcludingSelf undefined in lite, to solve moved > > > definition from generated_message_reflection.h to repeated_field.cc > > > > > 2) bool DescriptorPoolExtensionFinder::Find(int number, ExtensionInfo* > > > output) undefined in lite and i think it can be only solved by > > > removing DescriptorPoolExtensionFinder class declaration from the > > > extension_set.h and placing it in to a new file in libprotobuf > > > extension_set_heavy.h or somewhere else in libprotobuf local headers. > > > > > On Dec 23, 3:51 am, Kenton Varda wrote: > > > > If you link protobuf as a DLL: > > > > > > (1) You must link to the C runtime as a DLL, otherwise you'll end up > with > > > > two copies of the C runtime, which may mean two separate heaps, among > > > other > > > > things. > > > > > > (2) All components of your application which use protocol buffers > must > > > link > > > > to the same C runtime as the protocol buffers DLL. This is true when > > > static > > > > linking as well, but sometimes people mistakenly think that it is not > > > true > > > > with DLLs. > > > > > > (3) All components of your application which use protocol buffers > must > > > use > > > > the same version of protocol buffers. The DLL binary interface is > not > > > > compatible between two different versions. > > > > > > (4) You absolutely cannot place the protobuf DLL in a system shared > > > > directory, because it may be incompatible with other apps which use a > > > > different version of the DLL. The DLL has to stay in your > application's > > > own > > > > directory. > > > > > > Given these constraints, there isn't much benefit to dynamic linking > for > > > > most people. Usually the advantage of using a DLL is that you can > share > > > it > > > > between multiple programs, but that is unlikely to work well with > > > protocol > > > > buffers due to the interface version compatibility issues. > > > > > > Another typical reason to use DLLs is because you want to provide a > > > "plugin" > > > > system for your application. But if all your plugins link against > > > > libprotobuf as a DLL, then they must all use the same version of > protocol > > > > buffers, which is a pretty serious limitation to any plugin system. > A > > > > better approach would be to statically link each plugin individually > > > against > > > > protocol buffers; this way, each plugin has its own embedded copy and > > > > doesn't have to worry about version compatibility with other plugins. > > > > However, if you do this, then you cannot pass protocol buffer > objects > > > > between plugins, since they might use different versions of the > library. > > > You > > > > can, however, pass encoded messages between plugins -- the encoding > > > format > > > > is (obviously) compatible between versions. > > > > > > On Mon, Dec 21, 2009 at 5:21 PM, Soth wrote: > > > > > Hi, > > > > > in protobuf documentation it`s stated that static linking is > preferred > > > > > to dynamic because of different issues. I`d like to know what these > > > > > issues are, what i shouldnt do with the protobuf if i link with it > > > > > dynamically and how come that static linking is better. Thanks > ahead. > > > > > > > -- > > > > > > > You received this message because you are subscribed to the Google > > > Groups > > > > > "Protocol Buffers" group. > > > > > To post to this group, send email to proto...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > protobuf+unsubscr...@googlegroups.com > > > > > > > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/protobuf?hl=en.-Hide quoted text - > > > > > > - Show quoted text - > > > > > -- > > > > > You received this message because you are subscribed to the Google > Groups > > > "Protocol Buffers" group. > > > To post to this group, send email to proto...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > protobuf+unsubscr...@googlegroups.com > > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/protobuf?hl=en. > > -- > > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to proto...@googlegroups.com. > To unsubscribe from this group, send email to > protobuf+unsubscr...@googlegroups.com > . > For
Re: [protobuf] Re: Windows Dll
What version did you try this with? On Thu, Dec 24, 2009 at 3:38 PM, Soth wrote: > Hi, > I`ve tried to compile the protocol buffers library as a DLL in > msvs2008 and it didn`t link. The problems are basically with incorrect > export of functions/classes from the libprotobuf-lite and > libprotobuf : > > 1) StringSpaceUsedExcludingSelf undefined in lite, to solve moved > definition from generated_message_reflection.h to repeated_field.cc > > 2) bool DescriptorPoolExtensionFinder::Find(int number, ExtensionInfo* > output) undefined in lite and i think it can be only solved by > removing DescriptorPoolExtensionFinder class declaration from the > extension_set.h and placing it in to a new file in libprotobuf > extension_set_heavy.h or somewhere else in libprotobuf local headers. > > On Dec 23, 3:51 am, Kenton Varda wrote: > > If you link protobuf as a DLL: > > > > (1) You must link to the C runtime as a DLL, otherwise you'll end up with > > two copies of the C runtime, which may mean two separate heaps, among > other > > things. > > > > (2) All components of your application which use protocol buffers must > link > > to the same C runtime as the protocol buffers DLL. This is true when > static > > linking as well, but sometimes people mistakenly think that it is not > true > > with DLLs. > > > > (3) All components of your application which use protocol buffers must > use > > the same version of protocol buffers. The DLL binary interface is not > > compatible between two different versions. > > > > (4) You absolutely cannot place the protobuf DLL in a system shared > > directory, because it may be incompatible with other apps which use a > > different version of the DLL. The DLL has to stay in your application's > own > > directory. > > > > Given these constraints, there isn't much benefit to dynamic linking for > > most people. Usually the advantage of using a DLL is that you can share > it > > between multiple programs, but that is unlikely to work well with > protocol > > buffers due to the interface version compatibility issues. > > > > Another typical reason to use DLLs is because you want to provide a > "plugin" > > system for your application. But if all your plugins link against > > libprotobuf as a DLL, then they must all use the same version of protocol > > buffers, which is a pretty serious limitation to any plugin system. A > > better approach would be to statically link each plugin individually > against > > protocol buffers; this way, each plugin has its own embedded copy and > > doesn't have to worry about version compatibility with other plugins. > > However, if you do this, then you cannot pass protocol buffer objects > > between plugins, since they might use different versions of the library. > You > > can, however, pass encoded messages between plugins -- the encoding > format > > is (obviously) compatible between versions. > > > > > > > > On Mon, Dec 21, 2009 at 5:21 PM, Soth wrote: > > > Hi, > > > in protobuf documentation it`s stated that static linking is preferred > > > to dynamic because of different issues. I`d like to know what these > > > issues are, what i shouldnt do with the protobuf if i link with it > > > dynamically and how come that static linking is better. Thanks ahead. > > > > > -- > > > > > You received this message because you are subscribed to the Google > Groups > > > "Protocol Buffers" group. > > > To post to this group, send email to proto...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > protobuf+unsubscr...@googlegroups.com > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/protobuf?hl=en.- Hide quoted text - > > > > - Show quoted text - > > -- > > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to proto...@googlegroups.com. > To unsubscribe from this group, send email to > protobuf+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
