Re: stage1 libtool problem

On Thu, 3 Oct 2002 21:03:43 -0700 (PDT)
Brian Gartner <[email protected]> wrote:

> I'm switching from a heavily modified version of Mandrake to Gentoo, and
> running into difficulty. I'm using the 1.4-rc1 stage 1 tarball from the
> UT2003 demo iso cd, and have no problems at all until I execute the
> bootstrap.sh script. It runs fine until it decides to install libtool. I
> then get the following output:
> 
> 	>>> md5 ;-) libtool-1.4.1.tar.gz
> 	>>> Unpacking source...
> 	>>> Unpacking libtool-1.4.1.tar.gz
> 	patch: **** Can't create file /root/tmp/po3YJDgm : Permission
> denied
> 
> 	!!! ERROR: The ebuild did not complete successfully.
> 	!!! Function src_unpack, Line -106, Exitcode 2
> 	!!! (no error message)

<snip>

> 
>    Calculating dependencies ...done!
>    >>> emerge sys-devel/libtool-1.4.1-r9 to /
>    + /usr/sbin/ebuild.sh clean
>    + dyn_clean
>    + rm -rf /var/tmp/portage/libtool-1.4.1-r9/work
>    + rm -rf /var/tmp/portage/libtool-1.4.1-r9/image
>    + rm -rf /var/tmp/portage/libtool-1.4.1-r9/build-info
>    + rm -rf /var/tmp/portage/libtool-1.4.1-r9/.compiled
>    + set +x
>    >>> md5 ;-) libtool-1.4.1.tar.gz
>    + dyn_setup
>    + pkg_setup
>    + return
>    + set +x
>    + dyn_unpack
>    + trap abort_unpack SIGINT SIGQUIT
>    + local newstuff=no
>    + '[' -e /var/tmp/portage/libtool-1.4.1-r9/work ']'
>    + '[' -e /var/tmp/portage/libtool-1.4.1-r9/work ']'
>    + install -m0700 -d /var/tmp/portage/libtool-1.4.1-r9/work
>    + '[' -d /var/tmp/portage/libtool-1.4.1-r9/work ']'
>    + cd /var/tmp/portage/libtool-1.4.1-r9/work
>    + echo '>>> Unpacking source...'
>    >>> Unpacking source...
>    + src_unpack
>    + unpack libtool-1.4.1.tar.gz
>    + local x
>    + local y
>    + local myfail
>    + myfail=failure unpacking libtool-1.4.1.tar.gz
>    + echo '>>> Unpacking libtool-1.4.1.tar.gz'
>    >>> Unpacking libtool-1.4.1.tar.gz
>    ++ echo libtool-1.4.1.tar.gz
>    ++ sed 's:.*\.\(tar\)\.[a-zA-Z0-9]*:\1:'
>    + y=tar
>    + '[' tar == tar ']'
>    + tar xz --no-same-owner -f /usr/portage/distfiles/libtool-1.4.1.tar.gz
>    + cd /var/tmp/portage/libtool-1.4.1-r9/work/libtool-1.4.1
>    + patch -p1
>    patch: **** Can't create file /root/tmp/poutnNhF : Permission denied

Aha! The patches which the build is trying to apply (in the src_unpack()
section of the ebuild after untarring) aren't applying properly. That
error there comes from the patch command itself. Firstly, re-emerge your
Portage tree with:

  emerge rsync

because the patches are stored under the "files" subdirectory of
/usr/portage/sys-devel/libtool, not the distfile itself. You could
conceivably have a mismatch between the patches and the distfile itself
which only an rsync would cure (unless someone sends you the patches).

Next, have a look at the ebuild:

  nano -w /usr/portage/sys-devel/libtool-1.4.1-r9.ebuild

Make sure the src_unpack() section looks like this:

  src_unpack() {                                                                  
        unpack ${A}                                                             
                                                                                
        # Fix the relink problem where the relinked libs do not get             
        # installed.  It is *VERY* important that you get a updated             
        # 'libtool-${PV}-relink.patch' if you update this, as it                
        # fixes a very serious bug.  Please not that this patch is              
        # included in 'libtool-${PV}-gentoo.patch' for this ebuild.             
        #                                                                       
        # NOTE: all affected apps should get a 'libtoolize --copy --force'      
        #      added to upate libtool                                           
        #                                                                       
                                                                                
        cd ${S}                                                                 
        patch -p1 <${FILESDIR}/${PV}/${P}-nonneg.patch || die                   
        patch -p0 <${FILESDIR}/${PV}/${P}-relink.patch || die                   
        #fixes quoting for test's .. *VERY* important!                          
        patch -p0 <${FILESDIR}/${PV}/${P}-test.patch || die                     
        patch -p1 <${FILESDIR}/${PV}/${P}-duplicate-dependency.patch || die     
        patch -p0 <${FILESDIR}/${PV}/${P}-ltmain.sh-hack.patch || die           
        # Do not create bogus entries in $dependency_libs or $libdir            
        # with ${D} or ${S} in them.                                            
        #                                                                       
        # Azarah - 07 April 2002                                                
        patch -p0 <${FILESDIR}/${PV}/${P}-portage.patch-v6 || die               
  }       

When it comes down to it, it seems like one of two things are occurring:

1) For some reason Portage isn't in the correct folder when it tries to
patch
2) One of the patches contains a dud path (hence the /root
business)

The cd ${S} really should be taking care of number (1). There's no
reason you can't put some lines in to give you some more feedback. For
example you could insert this:

  cd ${S}
  echo ${S}
  die

to see if it really is in the right path at the time.

If you need to find out which patch is causing the problem then you
should be able to change the appropriate lines something like this:

  patch thispatch.patch || echo "thispatch patch didn't work!!!" && die

where obviously you are just changing the error handling in such a way
that you will get a message clearly telling you which patch failed when
you next try to emerge. Also, you could have a look at bugs.gentoo.org
and the forums too to see if anyone else has ever had this problem, if
you haven't already.

HTH, let me know if you get it sorted.

--kerframil