Re: [libextractor] Re: libextractor and Solaris 10

[Christian Grothoff]

On Tuesday 28 March 2006 03:54, Michał Kowalczuk wrote:
> Michał Kowalczuk wrote:
> > I needed to compile libextractor-0.5.11 on Solaris 10. [...cut...]
>
> There are also several problems, when compiling under Solaris 10 on 64-bit
> SPARC.
>
> 1) After configure I get such line in src/plugins/pdf/Makefile:
> CXXFLAGS = -O0
> that forces no optimisation. But it also forces to ignore other flags, that
> were given to configure (for example CXXFLAGS=-m64), which obviously breaks
> build process with error:
> ld: fatal: file .libs/Array.o: wrong ELF class: ELFCLASS32
> ld: fatal: File processing errors. No output written to
> .libs/libextractor_pdf.so
>
> My workaround for now is to declare CXX="g++ -m64"

I think we can do better.  Changing the CFLAGS line in Makefile.am to

CXXFLAGS = `echo "$(CFLAGS) -O0" | sed -e "s/-O?//"`

should do the trick -- disable optimizations while keeping the other flags
(in SVN 2611).

> 2) Build crashes with the following error:
> g++ -m64 -shared -nostdlib
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o
> /usr/ccs/lib/sparcv9/values-Xa.o
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o 
> .libs/Array.o .libs/Catalog.o .libs/Decrypt.o .libs/Dict.o .libs/Error.o
> .libs/FontEncoding.o .libs/FontFile.o .libs/Function.o .libs/GString.o
> .libs/Lexer.o .libs/Link.o .libs/Object.o .libs/PDFDoc.o .libs/Page.o
> .libs/Params.o .libs/Parser.o .libs/Stream.o .libs/XRef.o .libs/gfile.o
> .libs/gmem.o .libs/gmempp.o .libs/parseargs.o .libs/pdfextractor.o
> .libs/libextractor_pdf.lax/libconvert.a/convert.o   -Wl,-R
> -Wl,/home/sammael/SerweryWP/wpserver-all/mail_icons/libextractor/src/main/.
>libs -Wl,-R -Wl,/usr/sfw/lib -Wl,-R -Wl,/usr/local/lib -Wl,-R
> -Wl,/usr/sfw/lib ../../../src/main/.libs/libextractor.so
> -L/home/sammael/SerweryWP/wpserver-all/mail_icons/libextractor/libltdl/.lib
>s -lresolv -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9
> -L/usr/ccs/lib/sparcv9
> -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9
> -L/lib/sparcv9 -L/usr/lib/sparcv9 /usr/sfw/lib/libstdc++.so -L/usr/sfw/lib
> -lm
> -lgcc_s_sparcv9
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtend.o
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtn.o  -m64 -Wl,-h
> -Wl,libextractor_pdf.so -o .libs/libextractor_pdf.so
> ld: fatal: file /usr/sfw/lib/libstdc++.so: wrong ELF class: ELFCLASS32
> ld: fatal: File processing errors. No output written to
> .libs/libextractor_pdf.so collect2: ld returned 1 exit status
> *** Error code 1
> make: Fatal error: Command failed for target `libextractor_pdf.la'
> Current working directory
> /home/sammael/SerweryWP/wpserver-all/mail_icons/libextractor/src/plugins/pd
>f
>
> Do you have any ideas what to do with it? When I invoke this huge g++
> command by hand, replacing /usr/sfw/libstdc++.so with
> /usr/sfw/64/libstdc++.so, everything is fine, but I don't know how to pass
> using it to configure script.

No clue.  However, this maybe actually a problem with your g++ setup or with 
autotools macros for C++ on Sparc64 in general -- at least it does not look 
LE specific to me at all.

Other people seem to have had similar problems (however, without autotools):
http://utcc.utoronto.ca/~cks/space/blog/solaris/2006/02/10/

and maybe more to the point:

http://setiathome.berkeley.edu/forum_thread.php?id=20499

Now, setting LD_LIBRARY_PATH is clearly a hack, ideally IMO this should be 
handled by autoconf.  Do other C++ applications compile cleanly?  What do 
their configure.ac scripts look like?

Happy hacking!

Christian