Re: porting libtool for PCC compiler

[Ralf Wildenhues]

Hello Jeremy,

* Jeremy C. Reed wrote on Tue, Feb 19, 2008 at 06:24:18PM CET:
> I'd like to port libtool for the pcc compiler. I use it on DragonFly, 
> NetBSD and sometimes on Linux operating systems.

Great!

> The "Porting libtool to new systems" documentation suggests I contact your 
> list:
> 
> - anyone else working on this? (so we don't duplicate effort)

Not that I know of, but that doesn't mean much.  You may want to wait a
bit for someone to reply here, also asking the PCC devs may be useful.

> - and any advice on the most effective way of accomplishing adding pcc 
> support?

Very helpful for both adding support, and reviewing the resulting patch,
are pointers to the compiler (and linker) manuals.

Start off with a compiler setup that is close.  If you prefer to just
modify the libtool script before diving into libtool.m4, then check out
CVS HEAD Libtool, bootstrap and configure it with, say, GCC, modify the
libtool script until it fits what you think.  For testing just that
libtool script, use
  make check-local TESTSUITEFLAGS='-k libtool'

Rinse and repeat until you're happy with tests/testsuite.log.
(Libtool 1.5.x aka. branch-1-5 does not contain these testsuite bits).

For finally putting the support into libtool.m4, you can look at the
linux* bits which already handle multiple compilers in most places.

You should use pcc* (and not cc*) to match PCC.  The * is to allow for
versioned binaries.

> The documentation I read is mostly for adding a new operating system 
> platform and not for different compiler.

True.

> Note at this time I will be using the same linker. I am only using a 
> different compiler. Also pcc is not a C++ compiler.

Then in above, when configuring (for GCC), use
  configure ... CXX=no F77=no FC=no GCJ=no

so you don't run into any issues there.

> Here is an example of errors I receive using pcc instead of gcc with 
> libtool:
> 
> libtool  pcc -o db_archive -Wl,-R/home/reed/pkg/lib db_archive.o err.o 
> getlong.o libdb2.la 
> *** Warning: inferring the mode of operation is deprecated.
> *** Future versions of Libtool will require --mode=MODE be specified.

To avoid this warning, set LTCC and CC to pcc in the libtool script.

> pcc -o .libs/db_archive -Wl,-R/home/reed/pkg/lib db_archive.o err.o 
> getlong.o  ./.libs/libdb2.so 
> -L/build/reed/tmp/pkgsrc/databases/db/work.reed/.buildlink/lib  
> -Wl,--rpath -Wl,/home/reed/pkg/lib
> /usr/libexec/binutils217/elf/ld: warning: type and size of dynamic symbol 
> `log_archive' are not defined
> /usr/libexec/binutils217/elf/ld: dynamic variable `log_archive' is zero 
> size

How was log_archive defined, and how was the translation unit it was
defined in translated?

> /usr/libexec/binutils217/elf/ld: db_archive.o(.text+0x33d): unresolvable 
> R_386_PC32 relocation against symbol `log_archive'

This indicates that you need to generate PIC code.  pcc should have a
flag like -fPIC (other likely spellings: -KPIC -fpic) to generate
position-independent code.  Otherwise, it is not suitable for shared
library generation; then pcc should be fixed first.

> /usr/libexec/binutils217/elf/ld: final link failed: Nonrepresentable 
> section on output
> *** Error code 

Hope that helps.

Cheers,
Ralf