Kenton Varda wrote:
> I'm pretty sure #1 is not protobuf's fault.  I've never heard of
> libgcc_s which means it's probably something GCC links against
> implicitly.  And anyway, if libwhatever.so.1 exists, there should always
> be a libwhatever.so symlink to it... right?

Sorry - I haven't done any testing with gcc 3.4 on Solaris of any sort.
I'm only building with either Sun Studio or gcc 4.4. I agree it sounds
like something weird, but I don't have any info. I _do_ know that the
out-of-the-box gcc install on solaris is rather broken in a few ways.
(/me asks people to ignore that he works for Sun as he says that)

Any chance you can use Sun Studio for your work instead of gcc?

> Monty, can you comment on #2?

> I tracked this down to:
> - predeps_objects_CXX is being set incorrectly in configure because ..
> - output_verbose_link_command is doing a 32-bit link because ..
> - it uses CFLAGS and CFLAGS does not contain "-m64" because ..
> - the handling of --{en,dis}sable-64bit-solaris only puts "-m64" in
> CXXFLAGS, and not also in CFLAGS

Very odd. CFLAGS shouldn't matter because there is no non-C++ code
anywhere. (I specifically left CFLAGS off, although I suppose it
wouldn't hurt anything to add it.) Any chance in your tracking it down
you could tell me more info about why predeps_objects_CXX depends on
settings from CFLAGS?

> Also, I noticed that the Solaris 64-bit specific logic would modify
> libdir even if it didn't modify CXXFLAGS because it was passed in on
> the command line.

Good catch. I can (and will) fix this, both here and in pandora-build. I
will not fix this right now, as I have already had too much beer tonight
- but I should have a patch for this real soon.

Monty

> On Fri, Aug 21, 2009 at 7:44 PM, Oliver Jowett <oliver.jow...@gmail.com
> <mailto:oliver.jow...@gmail.com>> wrote:
> 
> 
>     I had some trouble getting 2.2.0 built in 64-bit mode on a Solaris 10
>     amd64 machine, and searching didn't turn much up. Here are my notes in
>     case someone else ends up with the same problems.
> 
>     Environment:
> 
>     $ uname -a
>     SunOS trouble 5.10 Generic_139556-08 i86pc i386 i86pc
> 
>     [prophetic machine name!]
> 
>     $ g++ -v
>     Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
>     Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
>     --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
>     --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
>     --enable-shared
>     Thread model: posix
>     gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
> 
> 
>     Problems:
> 
>     (1) Linking fails to find -lgcc_s.
> 
>     I had to create a symlink in /usr/sfw/lib/amd64 from libgcc_s.so to
>     libgcc_s.so.1 before it'd find it. I'm not sure if this is a problem on
>     the protobuf side or whether the GCC install on this machine is slightly
>     broken.
> 
>     (2) Linking fails because libtool is pulling in the 32-bit versions of
>     various runtime helper objects (crti.o, etc), not the 64-bit ones.
> 
>     I tracked this down to:
>     - predeps_objects_CXX is being set incorrectly in configure because ..
>     - output_verbose_link_command is doing a 32-bit link because ..
>     - it uses CFLAGS and CFLAGS does not contain "-m64" because ..
>     - the handling of --{en,dis}sable-64bit-solaris only puts "-m64" in
>     CXXFLAGS, and not also in CFLAGS
> 
>     Workaround: ./configure CFLAGS=-m64
> 
>     ...
> 
>     I don't know about (1), but (2) certainly looks like it can be fixed on
>     protobuf side.
> 
>     Also, I noticed that the Solaris 64-bit specific logic would modify
>     libdir even if it didn't modify CXXFLAGS because it was passed in on the
>     command line.
> 
>     This can lead to confusing things like configuring with
>     CXXFLAGS="something without -m64" and ending up with a library installed
>     in a directory that doesn't match the compiled target at all (e.g.
>     32-bit library in $prefix/lib/amd64).
> 
>     -O
> 
> 
> 
> 
> 
> > 


--~--~---------~--~----~------------~-------~--~----~
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