Bug 63944 - bsd.port.mk: use LIBTOOL from ports
Summary: bsd.port.mk: use LIBTOOL from ports
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Ade Lovett
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-08 21:00 UTC by Oliver Eikemeier
Modified: 2004-07-07 17:59 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Eikemeier 2004-03-08 21:00:34 UTC 
Even when USE_LIBTOOL is set, most ports use their own libtool, not
the one provided by ports.

Typically, those ports contain the following lines:
  # Always use our own libtool.
  LIBTOOL='$(SHELL) $(top_builddir)/libtool'

See security/heimdal or net/openldap*

Fix: 

Add
  -e '/^LIBTOOL=/s^\$$(top_builddir)/libtool^${LIBTOOL}^g'
to the sed expression in the patch-libtool target in bsd.port.mk

Not sure if this will break some ports, though. At least the
pkg-plist of ports the have USE_LIBTOOL and install .la files
will be incorrect after this patch.
Comment 1 Oliver Eikemeier freebsd_committer freebsd_triage 2004-03-08 21:01:46 UTC 
Responsible Changed
From-To: freebsd-ports-bugs->portmgr

ports infrastructure
Comment 2 Kris Kennaway 2004-03-21 02:33:51 UTC 
On Mon, Mar 08, 2004 at 01:02:12PM -0800, Oliver Eikemeier wrote:
> Synopsis: bsd.port.mk: use LIBTOOL from ports
> 
> Responsible-Changed-From-To: freebsd-ports-bugs->portmgr
> Responsible-Changed-By: eik
> Responsible-Changed-When: Mon Mar 8 22:01:46 CET 2004
> Responsible-Changed-Why: 
> ports infrastructure
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=63944


This will surely break a number of ports; if you are willing to fix
them all then I can do a separate build with this patch sometime.

Kris
Comment 3 Oliver Eikemeier 2004-03-21 09:44:51 UTC 
Kris Kennaway wrote:

> On Mon, Mar 08, 2004 at 01:02:12PM -0800, Oliver Eikemeier wrote:
> 
>>Synopsis: bsd.port.mk: use LIBTOOL from ports
>>
>>Responsible-Changed-From-To: freebsd-ports-bugs->portmgr
>>Responsible-Changed-By: eik
>>Responsible-Changed-When: Mon Mar 8 22:01:46 CET 2004
>>Responsible-Changed-Why: 
>>ports infrastructure
>>
>>http://www.freebsd.org/cgi/query-pr.cgi?pr=63944
> 
> This will surely break a number of ports; if you are willing to fix
> them all then I can do a separate build with this patch sometime.

Please do a seperate build and tell me how many ports this will break,
I can tell you whether I will be able to fix them all then...

It is expected to break some packing lists, since some ports have
USE_LIBTOOL without really using the ports libtool.
Comment 4 Kris Kennaway freebsd_committer freebsd_triage 2004-06-17 01:05:01 UTC 
State Changed
From-To: open->analyzed

Now testing on pointyhat to obtain list of affected ports.
Comment 5 Kris Kennaway 2004-06-18 07:47:30 UTC 
On Sun, Mar 21, 2004 at 10:44:51AM +0100, Oliver Eikemeier wrote:
> Kris Kennaway wrote:
> 
> >On Mon, Mar 08, 2004 at 01:02:12PM -0800, Oliver Eikemeier wrote:
> >
> >>Synopsis: bsd.port.mk: use LIBTOOL from ports
> >>
> >>Responsible-Changed-From-To: freebsd-ports-bugs->portmgr
> >>Responsible-Changed-By: eik
> >>Responsible-Changed-When: Mon Mar 8 22:01:46 CET 2004
> >>Responsible-Changed-Why: 
> >>ports infrastructure
> >>
> >>http://www.freebsd.org/cgi/query-pr.cgi?pr=63944
> >
> >This will surely break a number of ports; if you are willing to fix
> >them all then I can do a separate build with this patch sometime.
> 
> Please do a seperate build and tell me how many ports this will break,
> I can tell you whether I will be able to fix them all then...
> 
> It is expected to break some packing lists, since some ports have
> USE_LIBTOOL without really using the ports libtool. 

Build results are here:

http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.4-exp.2004061623/index.html

I'm not sure this change is worthwhile; unless the errors can be
solved globally without needing to make changes to lots of ports, it
seems like it's going to make it more difficult for people to get some
new software to work with the ports framework.

The following ports break for various reasons:

/usr/ports/arabic/katoob
/usr/ports/audio/ecawave
/usr/ports/audio/libmodplug
/usr/ports/comms/openobex
/usr/ports/databases/hk_classes
/usr/ports/databases/metakit
/usr/ports/devel/alf
/usr/ports/devel/arm-elf-gcc295
/usr/ports/devel/atlas
/usr/ports/devel/glib12
/usr/ports/devel/libcapsinetwork
/usr/ports/devel/libopendaap
/usr/ports/devel/m17n-lib
/usr/ports/devel/sdl12
/usr/ports/devel/vstr
/usr/ports/devel/zziplib
/usr/ports/emulators/libvm68k
/usr/ports/french/aspell
/usr/ports/german/aspell
/usr/ports/graphics/OpenEXR
/usr/ports/graphics/jasper
/usr/ports/graphics/libungif
/usr/ports/misc/skyutils
/usr/ports/net/dclib
/usr/ports/net/howl
/usr/ports/net/libpcapnav
/usr/ports/palm/synce-gnomevfs
/usr/ports/polish/aspell
/usr/ports/portuguese/aspell
/usr/ports/russian/aspell
/usr/ports/security/libgpg-error
/usr/ports/security/opensc-esteid
/usr/ports/sysutils/dar
/usr/ports/sysutils/progsreiserfs
/usr/ports/textproc/af-aspell
/usr/ports/textproc/aspell
/usr/ports/textproc/bg-aspell
/usr/ports/textproc/br-aspell
/usr/ports/textproc/ca-aspell
/usr/ports/textproc/cs-aspell
/usr/ports/textproc/cy-aspell
/usr/ports/textproc/da-aspell
/usr/ports/textproc/el-aspell
/usr/ports/textproc/eo-aspell
/usr/ports/textproc/es-aspell
/usr/ports/textproc/fo-aspell
/usr/ports/textproc/ga-aspell
/usr/ports/textproc/gd-aspell
/usr/ports/textproc/gl-aspell
/usr/ports/textproc/gv-aspell
/usr/ports/textproc/hr-aspell
/usr/ports/textproc/ia-aspell
/usr/ports/textproc/id-aspell
/usr/ports/textproc/is-aspell
/usr/ports/textproc/it-aspell
/usr/ports/textproc/libwpd
/usr/ports/textproc/mi-aspell
/usr/ports/textproc/ms-aspell
/usr/ports/textproc/mt-aspell
/usr/ports/textproc/nb-aspell
/usr/ports/textproc/nl-aspell
/usr/ports/textproc/nn-aspell
/usr/ports/textproc/ro-aspell
/usr/ports/textproc/sk-aspell
/usr/ports/textproc/sl-aspell
/usr/ports/textproc/sv-aspell
/usr/ports/textproc/sw-aspell
/usr/ports/textproc/tn-aspell
/usr/ports/textproc/tr-aspell
/usr/ports/textproc/wa-aspell
/usr/ports/textproc/zu-aspell
/usr/ports/ukrainian/aspell
/usr/ports/www/screem
/usr/ports/x11-toolkits/libxfce4gui
/usr/ports/x11-wm/bbconf
/usr/ports/x11/libICE
/usr/ports/x11/libXext
/usr/ports/x11/libXpm
/usr/ports/x11/libXrender

The following have plist errors:

/usr/ports/accessibility/at-spi
/usr/ports/accessibility/atk
/usr/ports/accessibility/gail
/usr/ports/accessibility/gnomemag
/usr/ports/archivers/lzo
/usr/ports/archivers/rpm
/usr/ports/archivers/ucl
/usr/ports/archivers/xpk
/usr/ports/astro/gpsdrive
/usr/ports/astro/libnova
/usr/ports/audio/Maaate
/usr/ports/audio/esound
/usr/ports/audio/flac
/usr/ports/audio/fluidsynth
/usr/ports/audio/gnomemedia2
/usr/ports/audio/id3lib
/usr/ports/audio/libao
/usr/ports/audio/libcdaudio
/usr/ports/audio/libcddb
/usr/ports/audio/libid3tag
/usr/ports/audio/libmad
/usr/ports/audio/libmikmod
/usr/ports/audio/libogg
/usr/ports/audio/libsamplerate
/usr/ports/audio/libshout2
/usr/ports/audio/libsndfile
/usr/ports/audio/libvorbis
/usr/ports/audio/libvorbis-aotuv
/usr/ports/audio/resid
/usr/ports/audio/speex
/usr/ports/biology/libgenome
/usr/ports/comms/gsmlib
/usr/ports/comms/libticables
/usr/ports/comms/lirc
/usr/ports/comms/vpb2
/usr/ports/converters/enca
/usr/ports/converters/fribidi
/usr/ports/converters/libiconv
/usr/ports/converters/mimelib
/usr/ports/converters/recode
/usr/ports/databases/freetds
/usr/ports/databases/freetds-msdblib
/usr/ports/databases/gdbm
/usr/ports/databases/libdbi
/usr/ports/databases/libgdamm
/usr/ports/databases/libgnomedb
/usr/ports/databases/libodbc++
/usr/ports/databases/libsdb
/usr/ports/databases/mdbtools
/usr/ports/databases/sybtcl
/usr/ports/databases/tdb
/usr/ports/databases/unixODBC
/usr/ports/databases/xbase
/usr/ports/databases/xbsql
/usr/ports/deskutils/glabels
/usr/ports/deskutils/gucharmap
/usr/ports/devel/ORBit2
/usr/ports/devel/arm-aout-binutils
/usr/ports/devel/boehm-gc
/usr/ports/devel/clint
/usr/ports/devel/gconf2
/usr/ports/devel/gconfmm
/usr/ports/devel/glib20
/usr/ports/devel/gnome-vfsmm
/usr/ports/devel/gnomebuild
/usr/ports/devel/leoarg
/usr/ports/devel/libIDL
/usr/ports/devel/libPropList
/usr/ports/devel/libassetml
/usr/ports/devel/libbonobomm
/usr/ports/devel/libffi
/usr/ports/devel/libfs++
/usr/ports/devel/libglade2
/usr/ports/devel/libglademm
/usr/ports/devel/libgsf
/usr/ports/devel/libgsf-gnome
/usr/ports/devel/libical
/usr/ports/devel/libidn
/usr/ports/devel/libshbuf
/usr/ports/devel/libsigc++
/usr/ports/devel/libsigc++12
/usr/ports/devel/libsoup
/usr/ports/devel/libstatgrab
/usr/ports/devel/libstroke
/usr/ports/devel/libticalcs
/usr/ports/devel/libtifiles
/usr/ports/devel/libukcprog
/usr/ports/devel/libunicode
/usr/ports/devel/log4c
/usr/ports/devel/lwp
/usr/ports/devel/ncurses
/usr/ports/devel/openzz
/usr/ports/devel/orbitcpp
/usr/ports/devel/oskit
/usr/ports/devel/pcre++
/usr/ports/devel/pcsc-lite
/usr/ports/devel/physfs
/usr/ports/devel/popt
/usr/ports/devel/privman
/usr/ports/devel/qtez
/usr/ports/devel/regexx
/usr/ports/devel/styx
/usr/ports/devel/swig13
/usr/ports/devel/tclreadline
/usr/ports/devel/varconf
/usr/ports/devel/xxl
/usr/ports/dns/idnkit
/usr/ports/editors/ghex2
/usr/ports/editors/mlview
/usr/ports/emulators/lib765
/usr/ports/finance/libofx
/usr/ports/french/med
/usr/ports/ftp/jigdo
/usr/ports/games/freecell-solver
/usr/ports/games/gnomegames2
/usr/ports/games/libmaitretarot
/usr/ports/games/libmt_client
/usr/ports/graphics/Hermes
/usr/ports/graphics/aalib
/usr/ports/graphics/gle
/usr/ports/graphics/glide3
/usr/ports/graphics/gltt
/usr/ports/graphics/gnofract4d
/usr/ports/graphics/lcms
/usr/ports/graphics/libart_lgpl2
/usr/ports/graphics/libexif
/usr/ports/graphics/libexif-gtk
/usr/ports/graphics/libgnomecanvas
/usr/ports/graphics/libgnomecanvasmm
/usr/ports/graphics/libgrass5
/usr/ports/graphics/libmorph
/usr/ports/graphics/librsvg2
/usr/ports/graphics/plotutils
/usr/ports/graphics/proj
/usr/ports/graphics/qglviewer
/usr/ports/graphics/quesa
/usr/ports/graphics/xmorph
/usr/ports/japanese/anthy
/usr/ports/japanese/eb
/usr/ports/japanese/uim
/usr/ports/java/jc
/usr/ports/java/sablevm
/usr/ports/lang/chicken
/usr/ports/lang/cim
/usr/ports/lang/libutils
/usr/ports/lang/njs
/usr/ports/lang/pm3-forms
/usr/ports/lang/pm3-gui
/usr/ports/lang/pm3-m3tk
/usr/ports/lang/pm3-net
/usr/ports/lang/pm3-netobj
/usr/ports/mail/dspam
/usr/ports/mail/gmime2
/usr/ports/mail/libesmtp
/usr/ports/mail/libetpan
/usr/ports/mail/postfix1
/usr/ports/math/cln
/usr/ports/math/fftw
/usr/ports/math/fftw3
/usr/ports/math/gsl
/usr/ports/math/libgmp4
/usr/ports/math/libmath++
/usr/ports/math/libneural
/usr/ports/math/p5-Math-Pari
/usr/ports/math/qhull
/usr/ports/math/spar
/usr/ports/misc/talkfilters
/usr/ports/multimedia/gstreamer-player
/usr/ports/multimedia/libdivxdecore
/usr/ports/multimedia/libdvdnav
/usr/ports/multimedia/libfame
/usr/ports/multimedia/libmpeg2
/usr/ports/net/fcptools
/usr/ports/net/gale
/usr/ports/net/gmdns
/usr/ports/net/gnet-glib2
/usr/ports/net/gnet2
/usr/ports/net/icqlib
/usr/ports/net/icqlib0
/usr/ports/net/libfreenet
/usr/ports/net/libicq2000
/usr/ports/net/libosip
/usr/ports/net/libosip2
/usr/ports/net/libsocket++
/usr/ports/net/linc
/usr/ports/net/loudmouth
/usr/ports/net/ntop
/usr/ports/net/ortp
/usr/ports/net/pvm++
/usr/ports/net/radiusclient
/usr/ports/net/tn5250
/usr/ports/net/xmlrpc-c
/usr/ports/palm/gnomepilot2
/usr/ports/print/freetype2
/usr/ports/print/gimp-print
/usr/ports/print/libgnomecups
/usr/ports/print/libgnomeprint
/usr/ports/print/libijs
/usr/ports/print/panda
/usr/ports/print/virtualpaper
/usr/ports/science/gchemutils
/usr/ports/security/beecrypt
/usr/ports/security/clamav-devel
/usr/ports/security/cyrus-sasl
/usr/ports/security/gnomekeyring
/usr/ports/security/gpgme
/usr/ports/security/heimdal
/usr/ports/security/libident
/usr/ports/security/libntlm
/usr/ports/security/libprelude
/usr/ports/security/libsectok
/usr/ports/security/libtasn1
/usr/ports/security/xmlsec
/usr/ports/sysutils/LPRng
/usr/ports/sysutils/file
/usr/ports/textproc/cole
/usr/ports/textproc/expat2
/usr/ports/textproc/gdome2
/usr/ports/textproc/latte
/usr/ports/textproc/libcroco
/usr/ports/textproc/liblingoteach
/usr/ports/textproc/liblrdf
/usr/ports/textproc/libparsifal
/usr/ports/textproc/libtre
/usr/ports/textproc/libxml
/usr/ports/textproc/libxml++
/usr/ports/textproc/libxode
/usr/ports/textproc/libxslt
/usr/ports/textproc/mifluz
/usr/ports/textproc/openjade
/usr/ports/textproc/raptor
/usr/ports/textproc/sary
/usr/ports/textproc/scrollkeeper
/usr/ports/textproc/wv
/usr/ports/textproc/xls2xml
/usr/ports/textproc/xmlpp
/usr/ports/ukrainian/iceb
/usr/ports/www/cgicc
/usr/ports/www/libghttp
/usr/ports/www/libgtkhtml
/usr/ports/www/libwww
/usr/ports/www/mnogosearch
/usr/ports/www/oops
/usr/ports/www/p5-WWW-Link
/usr/ports/x11-servers/driglide
/usr/ports/x11-toolkits/bakery
/usr/ports/x11-toolkits/bakery_gnomeui
/usr/ports/x11-toolkits/eel2
/usr/ports/x11-toolkits/fox-devel
/usr/ports/x11-toolkits/freeglut
/usr/ports/x11-toolkits/gal2
/usr/ports/x11-toolkits/gdl
/usr/ports/x11-toolkits/gtk--2
/usr/ports/x11-toolkits/gtk-sharp
/usr/ports/x11-toolkits/gtkglarea2
/usr/ports/x11-toolkits/gtkglext
/usr/ports/x11-toolkits/gtksourceview
/usr/ports/x11-toolkits/inti-gl
/usr/ports/x11-toolkits/libbonoboui
/usr/ports/x11-toolkits/libbonobouimm
/usr/ports/x11-toolkits/libgnomeprintui
/usr/ports/x11-toolkits/libgnomeui
/usr/ports/x11-toolkits/libgnomeuimm
/usr/ports/x11-toolkits/libpanelappletmm
/usr/ports/x11-toolkits/libwnck
/usr/ports/x11-toolkits/libzvt
/usr/ports/x11-toolkits/movingmotif
/usr/ports/x11-toolkits/neXtaw
/usr/ports/x11-toolkits/vdk
/usr/ports/x11-toolkits/vdkbuilder
/usr/ports/x11-toolkits/vte
/usr/ports/x11-toolkits/xbae
/usr/ports/x11-wm/expocity
/usr/ports/x11-wm/libdockapp
/usr/ports/x11-wm/metacity
/usr/ports/x11/ecore
/usr/ports/x11/gnomedesktop
/usr/ports/x11/gnomepanel
/usr/ports/x11/libgnome
/usr/ports/x11/libgnomemm
/usr/ports/x11/libxklavier
/usr/ports/x11/rxvt-devel
/usr/ports/x11/startup-notification

Kris
Comment 6 Kris Kennaway freebsd_committer freebsd_triage 2004-06-18 07:47:38 UTC 
State Changed
From-To: analyzed->feedback

Initial build complete.
Comment 7 Oliver Eikemeier 2004-06-18 08:49:04 UTC 
Kris Kennaway wrote:

> On Sun, Mar 21, 2004 at 10:44:51AM +0100, Oliver Eikemeier wrote:
>> [...]
>> It is expected to break some packing lists, since some ports have
>> USE_LIBTOOL without really using the ports libtool.
>
> Build results are here:
>
> http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.4-exp.2004061623/
> index.html
>
> I'm not sure this change is worthwhile; unless the errors can be
> solved globally without needing to make changes to lots of ports, it
> seems like it's going to make it more difficult for people to get some
> new software to work with the ports framework.

Hmmm... This is a huge list. OTOH these ports assume they use libtools 
from
ports, although they don't. The same is true for new software, 
essentially
they assume the FreeBSD version of LIBTOOLS with thread and .la fixes is 
used,
but it isn't.

I would suggest to introduce a new variable 'USE_INCLUDED_LIBTOOL' wich 
hinders
bsd.port.mk to patch the ports and set this in the affected ports.

Then we can inform the maintainers, and they can fix their port if they 
like to.

What do you think?
-Oliver
Comment 8 Oliver Eikemeier 2004-06-18 17:14:01 UTC 
Joe Marcus Clarke wrote:

> On Fri, 2004-06-18 at 03:49, Oliver Eikemeier wrote:
> 
>>Kris Kennaway wrote:
>>
>>>On Sun, Mar 21, 2004 at 10:44:51AM +0100, Oliver Eikemeier wrote:
>>>
>>>>[...]
>>>>It is expected to break some packing lists, since some ports have
>>>>USE_LIBTOOL without really using the ports libtool.
>>>
>>>Build results are here:
>>>
>>>http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.4-exp.2004061623/
>>>index.html
>>>
>>>I'm not sure this change is worthwhile; unless the errors can be
>>>solved globally without needing to make changes to lots of ports, it
>>>seems like it's going to make it more difficult for people to get some
>>>new software to work with the ports framework.

May I suggest the attached patch, and feeding the list of ports
into the following oneliner:

  xargs -n 1 -I % sed -n -e /USE_LIBTOOL_VER/s/1[345]/included/p %/Makefile

this should reduce the amount fo failing ports to a managable
amount. 

I'm not sure why stuff line audio/ecawave is failing, though. Basically
it should have been a noop for this port.

-Oliver

Index: bsd.autotools.mk
===================================================================
RCS file: /home/ncvs/ports/Mk/bsd.autotools.mk,v
retrieving revision 1.3
diff -u -r1.3 bsd.autotools.mk
--- bsd.autotools.mk	8 Jun 2004 20:44:59 -0000	1.3
+++ bsd.autotools.mk	18 Jun 2004 17:50:31 -0000
@@ -264,8 +264,10 @@
 
 .if defined(USE_LIBTOOL_VER)
 GNU_CONFIGURE?=		yes
+.if ${USE_LIBTOOL_VER:L} != "included"
 WANT_LIBTOOL_VER?=	${USE_LIBTOOL_VER}
 .endif
+.endif
 
 # Note that there aren't any non-versioned libtools, so we can skip
 # a little bit of cruft that exists in automake/autoconf above
@@ -377,6 +379,16 @@
 .if !target(patch-autotools)
 patch-autotools:
 .if defined(USE_LIBTOOL_VER)
+.if defined(WANT_LIBTOOL_VER)
+	 @(cd ${PATCH_WRKSRC}; \
+	 for file in ${LIBTOOLFILES}; do \
+		${CP} $$file $$file.tmp; \
+		${SED} -e "s^\$$ac_aux_dir/ltconfig^${LIBTOOL_SHAREDIR}/ltconfig${LIBTOOL_VERSION}^g" \
+			-e "/^ltmain=/!s^\$$ac_aux_dir/ltmain.sh^${LIBTOOLFLAGS} ${LIBTOOL_SHAREDIR}/ltmain.sh^g" \
+	 		-e '/^LIBTOOL=/s^\$$(top_builddir)/libtool^${LIBTOOL}^g' \
+			$$file.tmp > $$file; \
+	 done);
+.else
 	 @(cd ${PATCH_WRKSRC}; \
 	 for file in ${LIBTOOLFILES}; do \
 		${CP} $$file $$file.tmp; \
@@ -384,6 +396,7 @@
 			-e "/^ltmain=/!s^\$$ac_aux_dir/ltmain.sh^${LIBTOOLFLAGS} ${LIBTOOL_SHAREDIR}/ltmain.sh^g" \
 			$$file.tmp > $$file; \
 	 done);
+.endif
 .else
 	@${DO_NADA}
 .endif
Comment 9 Joe Marcus Clarke 2004-06-18 17:19:22 UTC 
On Fri, 2004-06-18 at 03:49, Oliver Eikemeier wrote:
> Kris Kennaway wrote:
> 
> > On Sun, Mar 21, 2004 at 10:44:51AM +0100, Oliver Eikemeier wrote:
> >> [...]
> >> It is expected to break some packing lists, since some ports have
> >> USE_LIBTOOL without really using the ports libtool.
> >
> > Build results are here:
> >
> > http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.4-exp.2004061623/
> > index.html
> >
> > I'm not sure this change is worthwhile; unless the errors can be
> > solved globally without needing to make changes to lots of ports, it
> > seems like it's going to make it more difficult for people to get some
> > new software to work with the ports framework.
> 
> Hmmm... This is a huge list. OTOH these ports assume they use libtools 
> from
> ports, although they don't. The same is true for new software, 
> essentially
> they assume the FreeBSD version of LIBTOOLS with thread and .la fixes is 
> used,
> but it isn't.


EXACTLY!  These ports should be fixed especially if they rely on threads
working on, say, 5.2-RELEASE.

> 
> I would suggest to introduce a new variable 'USE_INCLUDED_LIBTOOL' wich 
> hinders
> bsd.port.mk to patch the ports and set this in the affected ports.
> 
> Then we can inform the maintainers, and they can fix their port if they 
> like to.
> 
> What do you think?


This approach sounds okay to me.  The GNOME ports will definitely
benefit from this since we will be able to get rid of all the
lthacks/patch-ltmain.sh/patch-configure hacks we've had to do.

Joe

> -Oliver

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
Comment 10 Ade Lovett freebsd_committer freebsd_triage 2004-06-20 08:13:39 UTC 
On Jun 18, 2004, at 09:14, Oliver Eikemeier wrote:
> May I suggest the attached patch, and feeding the list of ports
> into the following oneliner:

Whilst, in principle, I have no major issue with the patch per-se, I 
would merely request two things:

	(1) that the next autotools-purge 4-exp run be put through first, 
which will
	    at least wipe out libtool14.
	(2) when all the autotools knobs get converted over to a single:
			USE_AUTOTOOLS= <tool>:<version>[:<options>], how does this patch fit 
in?

-aDe
Comment 11 Oliver Eikemeier 2004-06-20 08:34:42 UTC 
Ade Lovett wrote:

>
> On Jun 18, 2004, at 09:14, Oliver Eikemeier wrote:
>> May I suggest the attached patch, and feeding the list of ports
>> into the following oneliner:
>
> Whilst, in principle, I have no major issue with the patch per-se, I 
> would merely request two things:
>
> 	(1) that the next autotools-purge 4-exp run be put through first, 
> which will
> 	    at least wipe out libtool14.

I'm happy when you want to pick up from here. AFAICS there are only 
three ports
remaining, so it shouldn't be too hard.

> 	(2) when all the autotools knobs get converted over to a single:
> 			USE_AUTOTOOLS= <tool>:<version>[:<options>], how does 
> this patch fit in?

Basically USE_LIBTOOL_VER=included is equivalent to GNU_CONFIGURE=yes, 
so you
could do a simple search-and-replace. Currently it is useful the help 
identifying
the broken ports.
Comment 12 Joe Marcus Clarke freebsd_committer freebsd_triage 2004-06-25 22:57:01 UTC 
The more I think about this patch, the more I think it's wrong.  This
patch basically causes LIBTOOLFLAGS to be ignored.  What ends up
happening is a local libtool is built, but it is not used.  This breaks
some ports (e.g. glib12).

I think a better solution would be to simply use the ports version of
the ltmain.sh script to create the local, per-port, libtool; then use
that libtool to actually build the port.  I'll work on a patch for this
tonight.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	marcus@FreeBSD.org
gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
Comment 13 Oliver Eikemeier 2004-06-25 23:38:33 UTC 
Am Freitag den, 25. Juni 2004, um 23:57, schrieb Joe Marcus Clarke:

> The more I think about this patch, the more I think it's wrong.  This
> patch basically causes LIBTOOLFLAGS to be ignored.  What ends up
> happening is a local libtool is built, but it is not used.  This breaks
> some ports (e.g. glib12).
>
> I think a better solution would be to simply use the ports version of
> the ltmain.sh script to create the local, per-port, libtool; then use
> that libtool to actually build the port.  I'll work on a patch for this
> tonight.

Fine with me, go ahead. You will still have to cope with .la files in 
plists, though.

-Oliver
Comment 14 Joe Marcus Clarke freebsd_committer freebsd_triage 2004-06-26 00:02:08 UTC 
On Fri, 2004-06-25 at 18:38, Oliver Eikemeier wrote:
> Am Freitag den, 25. Juni 2004, um 23:57, schrieb Joe Marcus Clarke:
> 
> > The more I think about this patch, the more I think it's wrong.  This
> > patch basically causes LIBTOOLFLAGS to be ignored.  What ends up
> > happening is a local libtool is built, but it is not used.  This breaks
> > some ports (e.g. glib12).
> >
> > I think a better solution would be to simply use the ports version of
> > the ltmain.sh script to create the local, per-port, libtool; then use
> > that libtool to actually build the port.  I'll work on a patch for this
> > tonight.
> 
> Fine with me, go ahead. You will still have to cope with .la files in 
> plists, though.


I don't think so.  The ltmain.sh we install with the ports takes care of
those as well as some other things (like threading issues).

Joe

> 
> -Oliver

-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	marcus@FreeBSD.org
gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
Comment 15 Oliver Eikemeier 2004-06-26 10:00:26 UTC 
Am Samstag den, 26. Juni 2004, um 06:14, schrieb Joe Marcus Clarke:

> Okay, what about this?  Basically, eik's patch was good for the majority
> of ports, but it didn't allow us a way to use custom LIBTOOLFLAGS.  So
> instead of creating something totally new, I adapted it to work with
> ports like glib12 that need to set custom LIBTOOLFLAGS.  In doing so, I
> added a new macro, USE_INC_LIBTOOL_VER.
>
> USE_INC_LIBTOOL_VER is identical to USE_LIBTOOL_VER except it instructs
> b.a.m to use the old patch-autotools instead of the ports version of
> libtool.


The problem with this is that you still depend on 
devel/libtool${LIBTOOL_SUFFIX}, although it is not used in most cases, 
since its value is overridden with LIBTOOL=.

Also, if fail to see the difference between USE_LIBTOOL_VER and 
USE_INC_LIBTOOL_VER, maybe I'm overlooking something?

-Oliver
Comment 16 Ade Lovett freebsd_committer freebsd_triage 2004-07-07 17:56:57 UTC 
State Changed
From-To: feedback->closed

After some more discussion on irc, the best approach to looking at this 
is not to use GNATS and throw patches around here.  I suggest that eik, 
marcus, myself, and other interested parties get together either on ports@ 
(or possibly gnome@, since it's a big consumer of this), to thrash out the 
ideas, before coming up with an approach. 

I'm about 40% of the way through the autoconf->autoconf253 and 
automake->automake15 (last major autotools infrastructure change), at 
which point I'll be able to devote more time to extending things.
Comment 17 Ade Lovett freebsd_committer freebsd_triage 2004-07-07 17:56:57 UTC 
Responsible Changed
From-To: portmgr->ade

ade snuck the PR back from portmgr.  Blame me.  No-one else :)