On Wed, Aug 19, 2009 at 02:19, Kenton Varda<[email protected]> wrote: > The problem with these spec files is that they're large and complicated and > I just don't have time to learn how they work and maintain them. If someone > would like to commit to maintaining these things -- which means I'd call on > you to update them for each release, answer questions about them, etc., and > I'd need you to respond promptly (within a day or two) -- then we could add > them to the official package. Otherwise I'd prefer to stick with the > current decentralized approach.
I think you are right regarding spec file management: maintaining a generic spec that work for each RPM-based distribution is a lot of work. These files became a big mess really fast: think about supporting different distributions, distribution versions and architectures... That's a lot of possible combination ! I understand why you require such commitment and I agree with you. So +1 for the decentralized approach. BTW, should we continue packaging-related discussion of protobuf here ? > BTW, Kevin, I'm confused about this line in your changelog: > >> - Add -lpthread option to environment (else configure set it to -pthread) > > -pthread is the correct option, and it implies -lpthread. -pthread ensures > that the C runtime library uses thread-safe functions (e.g. errno becomes > thread-local) whereas -lpthread merely links against libpthread.so. Why did > you change this? Here is what happened when I don't force the "-lpthread" option. First, "configure" guess that we should use "-pthread": (...) checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking whether to check for GCC pthread/shared inconsistencies... yes checking whether -pthread is sufficient with -shared... yes checking the location of hash_map... <ext/hash_map> configure: creating ./config.status (...) Then the compilation fail: (...) libtool: link: x86_64-mandriva-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/crtbeginS.o .libs/common.o .libs/once.o .libs/hash.o .libs/extension_set.o .libs/generated_message_util.o .libs/message_lite.o .libs/repeated_field.o .libs/wire_format_lite.o .libs/coded_stream.o .libs/zero_copy_stream.o .libs/zero_copy_stream_impl_lite.o .libs/strutil.o .libs/substitute.o .libs/structurally_valid.o .libs/descriptor.o .libs/descriptor.pb.o .libs/descriptor_database.o .libs/dynamic_message.o .libs/extension_set_heavy.o .libs/generated_message_reflection.o .libs/message.o .libs/reflection_ops.o .libs/service.o .libs/text_format.o .libs/unknown_field_set.o .libs/wire_format.o .libs/gzip_stream.o .libs/printer.o .libs/tokenizer.o .libs/zero_copy_stream_impl.o .libs/importer.o .libs/parser.o -lz -L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/x86_64-manbo-linux-gnu/4.3.2/../../../../lib64/crtn.o -pthread -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -pthread -Wl,-soname -Wl,libprotobuf.so.4 -o .libs/libprotobuf.so.4.0.0 libtool: compile: x86_64-mandriva-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -MT python_generator.lo -MD -MP -MF .deps/python_generator.Tpo -c google/protobuf/compiler/python/python_generator.cc -o python_generator.o >/dev/null 2>&1 .libs/common.o: In function `InitShutdownFunctionsOnce': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' .libs/common.o: In function `GoogleOnceInit': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' .libs/common.o: In function `GoogleOnceInit': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/google/protobuf/stubs/common.cc:137: undefined reference to `pthread_once' .libs/extension_set.o: In function `GoogleOnceInit': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' /usr/bin/ld: Dwarf Error: Offset (391001) greater than or equal to .debug_str size (366455). .libs/descriptor.o: In function `InitGeneratedPoolOnce': /home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: undefined reference to `pthread_once' .libs/descriptor.o:/home/kevin/rpm/BUILD/protobuf-2.2.0/src/./google/protobuf/stubs/once.h:115: more undefined references to `pthread_once' follow collect2: ld returned 1 exit status make[2]: *** [libprotobuf.la] Erreur 1 make[2]: *** Attente des tâches non terminées.... mv -f .deps/python_generator.Tpo .deps/python_generator.Plo make[2]: quittant le répertoire « /home/kevin/rpm/BUILD/protobuf-2.2.0/src » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /home/kevin/rpm/BUILD/protobuf-2.2.0 » make: *** [all] Erreur 2 erreur: Mauvais status de sortie pour /home/kevin/rpm/tmp/rpm-tmp.yt8JOl (%build) Hence my hack, which consist of doing: export PTHREAD_CFLAGS="-lpthread" before calling "configure". To be honest I really don't have a clue of what happens. I've came up with this hack by browsing the web and I really don't understand what are its side-effects and shortcomings (if any). I've just observed that protobuf compiles and I moved on. :) Is this issue worth a bug report ? -- Kevin Deldycke • blog: http://kevin.deldycke.com • band: http://coolcavemen.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
