Thank you, I use -B static link option, and solve this problem. On Jan 20, 3:35 pm, Henner Zeller <[email protected]> wrote: > 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] > om> > .> 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.
