Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

2008-09-09 Thread Dmitry Marakasov
* Alexey Shuvaev ([EMAIL PROTECTED]) wrote:

 While the ports are in freeze just want to point to the problem I have
 encountered. Not sure if this is a critical bug, just a bug or not
 a bug at all (so, no PR yet).
This is definitely a bug, so better send-pr for this issue not to be
lost while we're in freeze.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
[EMAIL PROTECTED]  ..:  jabber: [EMAIL PROTECTED]http://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

2008-09-09 Thread Peter Pentchev
On Tue, Sep 09, 2008 at 05:20:06PM +0400, Dmitry Marakasov wrote:
 * Alexey Shuvaev ([EMAIL PROTECTED]) wrote:
 
  While the ports are in freeze just want to point to the problem I have
  encountered. Not sure if this is a critical bug, just a bug or not
  a bug at all (so, no PR yet).
 This is definitely a bug, so better send-pr for this issue not to be
 lost while we're in freeze.

I think Alexey's point might have been that this should be fixed during
the freeze, before 6.4 and 7.1 ship with the ports tree - and I think it
might be a good idea, if libtool uses sed (resp. gsed) in any files in
the already-built target application / library.  From a quick look,
that does not seem to be the case, but if it is, it's important.

What I mean is the following scenario:
- libfoo uses libtool for its build
- libfoo depends on libbar which depends on GNU sed
- during libfoo's build, libbar is built, thus gsed is installed
- during libfoo's build, libtool detects gsed installed and remembers it
- in libfoo's binary package, there is a shell script that uses gsed,
  because libtool knows gsed is present on the system
- an unsuspecting user installs the libfoo binary package without previously
  building libbar
- the unsuspecting user gets a shell script that tries to run gsed and
  fails.

Of course, this all hinges on the idea that libtool uses gsed in any
files that are part of the binary package.  From a quick look, the .la
files do not contain any shell commands apart from variable assignments,
but I'm not too familiar with libtool and I don't know if there are any
other files that it might generate in the binary package.

If libtool may put gsed into libfoo's binary package, this should be
fixed before the freeze.  If libtool only uses gsed during libfoo's
build, then it is not a critical problem.

Of course, if Dmitry is more familiar with libtool than I am, and he
knows that libtool does not leave any such files, then I've just wasted
everybody's time with unneeded idle speculation, for which I apologize :)

G'luck,
Peter

-- 
Peter Pentchev  [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
No language can express every thought unambiguously, least of all this one.


pgprZ8yIal68Y.pgp
Description: PGP signature


Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

2008-09-09 Thread Dmitry Marakasov
Here's the fix, btw.

Portrevision bump is to make users with gsed-tainted libtool to
rebuild it with correct sed.

--- libtool.patch begins here ---
Index: Makefile
===
RCS file: /home/pcvs/ports/devel/libtool15/Makefile,v
retrieving revision 1.62
diff -u -r1.62 Makefile
--- Makefile21 Aug 2008 06:16:44 -  1.62
+++ Makefile9 Sep 2008 16:02:47 -
@@ -7,6 +7,7 @@
 
 PORTNAME?= libtool
 PORTVERSION=   1.5.26
+PORTREVISION=  1
 CATEGORIES=devel
 MASTER_SITES=  ${MASTER_SITE_GNU}
 MASTER_SITE_SUBDIR=libtool
Index: files/patch-configure
===
RCS file: files/patch-configure
diff -N files/patch-configure
--- /dev/null   1 Jan 1970 00:00:00 -
+++ files/patch-configure   9 Sep 2008 16:02:47 -
@@ -0,0 +1,11 @@
+--- configure.orig 2008-02-01 19:38:42.0 +0300
 configure  2008-09-09 20:01:57.0 +0400
+@@ -3615,7 +3615,7 @@
+ do
+   IFS=$as_save_IFS
+   test -z $as_dir  as_dir=.
+-  for lt_ac_prog in sed gsed; do
++  for lt_ac_prog in sed; do
+ for ac_exec_ext in '' $ac_executable_extensions; do
+   if { test -f $as_dir/$lt_ac_prog$ac_exec_ext  $as_test_x 
$as_dir/$lt_ac_prog$ac_exec_ext; }; then
+ lt_ac_sed_list=$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext
--- libtool.patch ends here ---

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
[EMAIL PROTECTED]  ..:  jabber: [EMAIL PROTECTED]http://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

2008-09-09 Thread Alexey Shuvaev
On Tue, Sep 09, 2008 at 06:11:44PM +0400, Dmitry Marakasov wrote:
 * Peter Pentchev ([EMAIL PROTECTED]) wrote:
 
   This is definitely a bug, so better send-pr for this issue not to be
   lost while we're in freeze.
  What I mean is the following scenario:
  - libfoo uses libtool for its build
  - libfoo depends on libbar which depends on GNU sed
  - during libfoo's build, libbar is built, thus gsed is installed
  - during libfoo's build, libtool detects gsed installed and remembers it
 No, as previously built libtool package will be used, which doesn't
 use gsed for sure.
  - in libfoo's binary package, there is a shell script that uses gsed,
because libtool knows gsed is present on the system
  - an unsuspecting user installs the libfoo binary package without previously
building libbar
  - the unsuspecting user gets a shell script that tries to run gsed and
fails.
 ...
  If libtool may put gsed into libfoo's binary package, this should be
  fixed before the freeze.  If libtool only uses gsed during libfoo's
  build, then it is not a critical problem.
 Neither seem to be the case for package building.
 
  Of course, if Dmitry is more familiar with libtool than I am, and he
 I am most likely not,
  knows that libtool does not leave any such files, then I've just wasted
  everybody's time with unneeded idle speculation, for which I apologize :)
 but my vision is that the problem will only show itself if you build
 libtool with gsed installed and then deinstall gsed. Thus, you'll
 end up with defunct libtool and all ports which have
 USE_AUTOTOOLS=libtool:15 will fail to build.
 
I have encountered this with x11/libX11, FWIW.
The error was 'gsed not found' or something similar.

 Since this doesn't affect package builds, I don't this this is serious
 enough to fix duing freeze. But still to be fixed :)
 
Yes, but the releases will be bundled with a 'broken' devel/libtool15 port.
Many [new] users could be using this port tree for a rather long time...

I have filed PR with the proposed patch:
http://www.freebsd.org/cgi/query-pr.cgi?pr=127256

Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


devel/libtool15 unconditionally hardcodes autodetected textproc/gsed

2008-09-08 Thread Alexey Shuvaev
Hello all!

While the ports are in freeze just want to point to the problem I have
encountered. Not sure if this is a critical bug, just a bug or not
a bug at all (so, no PR yet).

If one installs/rebuilds devel/libtool15 while textproc/gsed is
installed, libtool autodetects it and hardcodes gsed in itself.
If later one removes gsed (and nothing prevents him from doing this),
libtool is left in a broken state. FWIW, textproc/gsed is a BUILD_DEPENDS
of some ports.

Ideally, I think, one should hack libtool's configure framework to
not detect gsed at all. Sorry, no patch here. Attached is the diff
between unpacked libtool packages, one built with system sed and
one - with gsed.

Alexey.
diff -ruN libtool-good/+CONTENTS libtool-bad/+CONTENTS
--- libtool-good/+CONTENTS  2008-09-08 10:29:34.0 +0200
+++ libtool-bad/+CONTENTS   2008-09-08 20:50:41.0 +0200
@@ -4,7 +4,7 @@
 @cwd /usr/local
 @comment $FreeBSD: ports/devel/libtool15/pkg-plist,v 1.13 2006/02/23 10:36:03 
ade Exp $
 bin/libtool
[EMAIL PROTECTED] MD5:d82d18482a1bdb6a66b4a88e5f6af477
[EMAIL PROTECTED] MD5:553962c30b1587c8cd17cd90a252a8f2
 bin/libtoolize
 @comment MD5:efbc69981145a9fac91f0f875ba11c3e
 share/aclocal/libtool.m4
diff -ruN libtool-good/bin/libtool libtool-bad/bin/libtool
--- libtool-good/bin/libtool2008-09-08 10:29:29.0 +0200
+++ libtool-bad/bin/libtool 2008-09-08 20:50:36.0 +0200
@@ -30,10 +30,10 @@
 # the same distribution terms that you use for the rest of that program.
 
 # A sed program that does not truncate output.
-SED=/usr/bin/sed
+SED=/usr/local/bin/gsed
 
 # Sed that helps us avoid accidentally triggering echo(1) options like -n.
-Xsed=/usr/bin/sed -e 1s/^X//
+Xsed=/usr/local/bin/gsed -e 1s/^X//
 
 # The HP-UX ksh and POSIX shell print the target directory to stdout
 # if CDPATH is set.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]