On Wed, Aug 19, 2009 at 02:19, Kenton Varda<ken...@google.com> 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 protobuf@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
-~----------~----~----~----~------~----~------~--~---

Reply via email to