mainGNU Libtool - Support: sr #108987, libtool doesn't like simple RM...

 
 

sr #108987: libtool doesn't like simple RM defined (without options)

Submitter:  Richard PALO <risto3>
Submitted:  Sun 28 Feb 2016 02:20:46 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 17 Jan 2024 07:00:40 AM UTC, comment #4: 

bootstrap & build-aux/funclib.sh are not maintained in libtool.  you'll want to send those fixes upstream.
https://github.com/gnulib-modules/bootstrap

Mike Frysinger <vapier>
Group Member
Wed 16 Mar 2016 09:40:46 PM UTC, comment #3: 

The attached patchsets seem to get over the issue for RM, as well as for eventual problems for CP or MV.

the first patchset (0001-*) is for the master libtool repo,
and the second (0002-*) is for gl-mod/bootstrap in order to
generate the new bootstrap correctly.

$ env RM=/bin/rm MV=/bin/mv CP=/bin/cp gmake check

seems fine now

Richard PALO <risto3>
Wed 02 Mar 2016 07:10:01 AM UTC, comment #2: 

It appears that the shell assignment expectation may be erroneous,
in that ": ${RM="rm -f"}" will only replace RM if RM is not defined.

perhaps what is intended is more along the lines of:
RM="${RM:=rm} -f"

(NB it would probably be easier to contend with separating
pure RM from, for example, RM_F (or RM_FORCE) for "rm -f").

This problematic construct seems to be found in at least the following files: bootstrap, libtool.in, libtool.m4 and funclib.sh

Richard PALO <risto3>
Sun 28 Feb 2016 03:57:36 PM UTC, comment #1: 

another simple, but enlightening way to see this is
$ env RM=/usr/bin/rm gmake
or
$ env RM=/usr/bin/rm gmake check

it appears to be more involved than simply updating '${RM}r' to '${RM} -r' in ltmain.in

Richard PALO <risto3>
Sun 28 Feb 2016 02:20:46 PM UTC, original submission:  

noticed on pkgsrc libtool 2.4.2 (patched)
as well as on master

libtool uses a construct in numerous places '${RM}r' where
if defined simply to the full path breaks miserably.

Here is a simple example (code source unimportant):

what works (this is after a --mode=compile stage):

richard@omnis:/home/richard/src/tlibtool$ ../libtool/libtool -v --tag=CXX --mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: rm -fr  .libs/libfoo.a .libs/libfoo.la
libtool: link: ar cr .libs/libfoo.a .libs/foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: creating libfoo.la
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" )

what doesn't:
richard@omnis:/home/richard/src/tlibtool$ RM=/usr/bin/rm ../libtool/libtool -v --tag=CXX --mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: /usr/bin/rmr  .libs/libfoo.a .libs/libfoo.la
../libtool/libtool[1851]: eval[1]: /usr/bin/rmr: not found [No such file or directory]
libtool: link: ar cr .libs/libfoo.a .libs/foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: creating libfoo.la
libtool: link: ( cd ".libs" && /usr/bin/rm "libfoo.la" && ln -s "../libfoo.la" "libfoo.la" )


libtool should naturally test RM prior to using as thus.

Richard PALO <risto3>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #36663:  0001-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch added by risto3 (1KiB - text/x-patch - patchsets to avoid issues if CP, MV or RM are predefined in the execution environment)
file #36664:  0002-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch added by risto3 (907B - text/x-patch - patchsets to avoid issues if CP, MV or RM are predefined in the execution environment)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by vapier (Posted a comment)
  • -email is unavailable- added by risto3 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-16 risto3 Attached File- Added 0001-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch, #36663
        Attached File- Added 0002-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch, #36664

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code