Re: minor issues when building ncurses-5.6 with libtool

[Michael Haubenwallner]

On Thu, 2008-03-20 at 13:49 -0400, Mike Frysinger wrote:
> On Thursday 20 March 2008, Michael Haubenwallner wrote:
> > there are two minor issues (depending on libtool and compiler used).
> > 1) The libtool object files are still called '.o' (should be '.lo').
> 
> err, no.  if a file ends in .o it means the object was built without PIC.  if 
> it ends in .lo it means the object was built with PIC.  it does not mean .lo 
> was built with libtool and .o was not.

AFAIK, .lo is the generic object file of libtool, being a text file,
basically containing two lines of shellcode:

        (linux)$ libtool --mode=compile --tag=CC gcc -c xx.c -o xx.o
        mkdir .libs
         gcc -c xx.c  -fPIC -DPIC -o .libs/xx.o
         gcc -c xx.c -o xx.o >/dev/null 2>&1
        (linux)$ cat xx.lo
        pic_object='.libs/xx.o'
        non_pic_object='xx.o'
        (linux)$ ls xx.o .libs/xx.o
        .libs/xx.o  xx.o


        (aix)$ libtool --mode=compile --tag=CC gcc -c xx.c -o xx.o
        mkdir .libs
         gcc xx.c -c  -DPIC -o .libs/xx.o
        (aix)$ cat xx.lo
        pic_object='.libs/xx.o'
        non_pic_object=none
        (aix)$ ls xx.o .libs/xx.o
        ls: cannot access xx.o: A file or directory in the path name does not 
exist.
        .libs/xx.o

This being said, I now understand what was the problem on AIX, why it
works on Linux, and why it was resolved when using .lo in Makefiles:

On AIX, with shared library being enabled, there is only the PIC object
'.libs/xx.o', but no 'xx.o' (being the Makefile target), while libtool
always creates 'xx.lo'.
Now when Makefile uses '.o', such object files never show up on the
filesystem. Thus, Makefile dependencies are broken even after successful
compile commands.

>From Makefile's POV, there should be no distinction between PIC and
non-PIC object, it simply should use .lo with libtool.

/haubi/