Fixed in revision 286. On Fri, Dec 25, 2009 at 2:28 PM, Kenton Varda <ken...@google.com> 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 <soth1...@yahoo.com> wrote: > >> I`m using 2.3.0rc1. >> >> On 25 дек, 07:07, Kenton Varda <ken...@google.com> wrote: >> > What version did you try this with? >> > >> > On Thu, Dec 24, 2009 at 3:38 PM, Soth <soth1...@yahoo.com> 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 <ken...@google.com> 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 <soth1...@yahoo.com> 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<protobuf%2bunsubscr...@googlegroups.com> >> <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegroups.com> >> > >> > > <protobuf%2bunsubscr...@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<protobuf%2bunsubscr...@googlegroups.com> >> <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@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<protobuf%2bunsubscr...@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.
