On Wed, Jan 19, 2011 at 23:02, triStone <[email protected]> wrote: > So if I want run the application in another machine, the only solution > is build protobuf on that machine? And if I have no permission to do > this, there are no way to make a application which use protobuf work > fine?
This has nothing to do with protocol buffers, this is a problem you have with all libraries that you link your binary with and you don't expect to be part of the other system. If the protocol buffer library is the first external library in your project, then you can consider several options. Typical solutions are 1. Statically link your binary fuly. This is the best solution if you really want to ship around binaries on sufficiently different machines and don't even trust libc on the target system. However, since it pulls in all libraries, the binary will be huge. And you might encounter other problems such as the getostbyname problem you've seen. 2. Distribute the binary together with all shared libraries you've compiled them. If you suspect that the system libraries are sufficiently 'good', that would be the proto buffer library plus other dynamic libraries your binary needs. If you pack these libraries into a non-system directory, you've to set the environment variable LD_LIBRARY_PATH to point to the directory. 3. Best for you might be to just link the libprotobuf library statically to your binary (that is the *.a file as opposed to the *.so file). This is the 'standard' way if you distribute a binary with a library that is typically not part of the system in the target configuration I'd go with option 3. Hope this helps (detailed descriptions to all these options you can find on 'the Internet'). -h > > Thanks. > > On Jan 20, 10:52 am, Adam Skutt <[email protected]> wrote: >> On Wed, Jan 19, 2011 at 9:15 PM, triStone <[email protected]> wrote: >> > Thanks. >> > But if I also use "gethostbyname" function. So when I add -static >> > option, there will be a warning like this. >> > warning: Using 'gethostbyname' in statically linked applications >> > requires at runtime the shared libraries from the glibc version used >> > for linking >> > I search this warning on the web, it seems a bug of glibc, and it >> > maybe cause the program crash. >> > So if I use static link, this program will crash, if I use dynamic >> > link, this program can't execute in other machine because no >> > "protobuf.so", how can I do? >> >> C++ and static linking doesn't really mix anyway, ignoring all the >> glibc issues that make static linking dangerous on Linux. >> >> You either need to provide the protobuf dynamic libraries with your >> application, or build it on your target machine. Note that if you >> ship the protobuf libraries to a machine with a different version of >> the C++ runtime installed, bad things will happen. You can ship that >> too, but that's quite a nightmare. I wouldn't bother with libraries >> if you're shipping source to the target machine like you appear to be >> doing, just build protobuf on that machine too. >> >> Adam > > -- > You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]<protobuf%[email protected]> . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
