[MacPorts] #27280: MacPort upgrade fails with readline in /usr/lib in Snow Leopard 10.6.4

[MacPorts]

#27280: MacPort upgrade fails with readline in /usr/lib in Snow Leopard 10.6.4
-----------------------------+----------------------------------------------
 Reporter:  vulcan_@…        |       Owner:  macports-tickets@…                   
     Type:  defect           |      Status:  new                                  
 Priority:  Normal           |   Milestone:                                       
Component:  ports            |     Version:  1.9.1                                
 Keywords:                   |        Port:  MacPorts                             
-----------------------------+----------------------------------------------
 noticed that MacPorts needed an upgrade ( 1.9.1 installed), ran it and
 when it got to building
 {{{:info:build ===> making all in src/pextlib1.0
 }}}
 I got this:
 {{{
 :info:build /usr/bin/gcc-4.2 -dynamiclib -pipe -O2 -arch x86_64 -arch i386
 -W -Wall -pedantic      -Wl,-single_module Pextlib.o strsed.o fgetln.o
 md5cmd.o setmode.o xinstall.o fs-traverse.o strcasecmp.o vercomp.o
 filemap.o sha1cmd.o curl.o rmd160cmd.o sha256cmd.o readline.o uid.o
 tracelib.o tty.o readdir.o pipe.o flock.o system.o mktemp.o realpath.o -o
 Pextlib.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.5
 -ltclstub8.5 -arch x86_64 -arch i386   -lcurl  -lreadline
 :info:build Undefined symbols:
 :info:build   "_rl_username_completion_function", referenced from:
 :info:build       _attempted_completion_function in readline.o
 :info:build ld: symbol(s) not found
 :info:build collect2: ld returned 1 exit status
 :info:build Undefined symbols:
 :info:build   "_rl_username_completion_function", referenced from:
 :info:build       _rl_username_completion_function$non_lazy_ptr in
 readline.o
 :info:build      (maybe you meant:
 _rl_username_completion_function$non_lazy_ptr)
 }}}

 google found reference to this exact set of error messages from a macports
 bug back in 2004?  well .. long long ago.  and the cause was a readline in
 /usr/local/lib

 but i saw that the library it was trying to use was the libreadline from
 /usr/lib.[[BR]]
 which is a link to libedit.dylib.  OB some strange Mac OS X thing .. so i
 hid the link and tried again.

 now it tried to use a libreadlib in /usr/local/lib and i got similar
 messages .. except that now the complaint was that there was no X86_86
 architecture variant in the library.  Which makes sense as my machine is a
 MacBook with and Intel Duo Core .. only 32 bit. The 64 bit variants should
 not be required.

 i moved the local/lib files out of the way and tried again.  Now it
 complained that it could not find the library at all.
 I check the Makefiles to see how dynamic libraries are being found.  I
 have not set env var LD_LIBRARY_PATH and i do not have /etc/ld.so.conf and
 there is no sign that /opt/local/lib is being searched.  Very Odd

 i find  the MacPorts Portfile and see that it is doing this
 {{{
 # Some of MacPort's default flags don't play well when we're building
 # MacPorts itself: nuke them
 configure.cppflags
 configure.ldflags
 }}}
 so it seems that when building the MacPorts itself the /opt/local/lib is
 not going to be searched. And there is no -L/opt/local/lib  flag on the
 link command in the build log (attached).  So the upgrade was still
 failing.

 fumbling around in the Portfile and re-trying the upgrade command had the
 result that the whole thing was rebuilt from the configuration stage .. so
 the Makefiles all got rebuilt.  Now when i re-tryed the upgrade it worked
 all the way through.  Note the libreadline.dylib files in /usr/lib and
 /usr/local/lib are still all moved out of the way. I see that the command
 to build pexlib is now NOT using readline
 {{{

 /usr/bin/gcc-4.2 -dynamiclib -pipe -O2 -arch x86_64 -arch i386 -W -Wall
 -pedantic      -Wl,-single_module Pextlib.o strsed.o fgetln.o md5cmd.o
 setmode.o xinstall.o fs-traverse.o strcasecmp.o vercomp.o filemap.o
 sha1cmd.o curl.o rmd160cmd.o sha256cmd.o readline.o uid.o tracelib.o tty.o
 readdir.o pipe.o flock.o system.o mktemp.o realpath.o -o Pextlib.dylib
 -L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5 -arch
 x86_64 -arch i386   -lcurl
 }}}
 and this kind of sucks as the readline.c file is full of code that would
 love to be using it.

 summary:
  * MacPorts port is configured to require both 64 and 32 bit architectures
 in the libreadline.dylib  on a Intel Duo Core running Snow Leopard that
 can only support 32 bit.
  * (NB the port for readline is building libreadline for both
 architectures - that is bad and deserves its own bug report )
  * MacPorts port leaves /usr/lib and /usr/local/lib in the search path for
 dynamic libs but can use only the MacPorts libreadline
  * MacPorts port configuration only enables the use of readline when a
 libreadline.dylib is found in /usr/lib or /usr/local/lib .. which then
 causes pextlib to fail to build.  /opt/local/lib is not searched for
 libraries and configure thus misses the only combination that will make
 use of the readline code in pextlib

-- 
Ticket URL: <https://trac.macports.org/ticket/27280>
MacPorts <http://www.macports.org/>
Ports system for Mac OS