Question on freeBSD (5.1-CURRENT) portupgrade of Perl 5.8andlibiconv 1.9.1_3

[Scott Wegener, Roadster Performance]

Joe Marcus Clarke wrote:

>On Wed, 2003-10-22 at 01:14, Scott W wrote:
>  
>
>>Hey all.  In doing a portupgrade -RvN for windowmaker, Perl and libiconv 
>>were recompiled.  I saved the log output and noticed several oddities I 
>>was wondering if anyone can explain?
>>
>>1..several settings come up as undefined during the Perl build, namely:
>>$i_malloc
>>$d_setegid
>>$d_seteuid
>>$i_iconv
>>
>>These don't look troubling by themselves dur to 'autoconf magic,' but 
>>the next one for libiconv is more bothersome:
>>
>> From libiconv 1.9.1_3 configure:
>>checking if libtool supports shared libraries... yes
>>
>>*** Warning: the command libtool uses to detect shared libraries,
>>*** /usr/bin/file, produces output that libtool cannot recognize.
>>*** The result is that libtool may fail to recognize shared libraries
>>*** as such.  This will affect the creation of libtool libraries that
>>*** depend on shared libraries, but programs linked with such libtool
>>*** libraries will work regardless of this problem.  Nevertheless, you
>>*** may want to report the problem to your system manager and/or to
>>*** bug-libtool at gnu.org
>>
>>Any ideas?
>>    
>>
>
>This is a byproduct of the new dynamic root layout in -CURRENT. 
>Basically, older versions of libtool try to do file on
>/usr/lib/libc.so.  Recent versions of -CURRENT put libc.so in /lib. 
>Therefore, this fails.  I haven't noticed any real problems because of
>this, but I have reported it to the libtool maintainer, ade at .
>  
>
Great.  That makes sense, as file will return symbolic link rather than 
an ELF executable, should be a minor adjustment by the maintainer.  Also 
makes sense on libc in /lib - always disturbs me when I see 'important' 
system binaries mounted on the /usr filesystem!

>>Also, is there a way to pass configure options to portupgrade, or should 
>>I run make clean && ./configure for each port in an 'upgrade chain' and 
>>then force portupgrade to not make clean prior to building/installing?
>>    
>>
>
>Configure arguments?  No.  However, you can use the -m option to pass
>make arguments (e.g. -DWITH_FOO).  To pass configure arguments, you'd
>have to edit the port Makefiles directly.
>
>Joe
>  
>

Actually, it _looks_ like there's somewhat of a standard in place within 
the port Makefiles defining CONFIGURE_ARGS, but I haven't searched 
through all of them- anyone know if this is a 'freeBSD Makefile 
standard' that can (generally) be counted on?  If so, at least for 
specific ports builds, you should be able to define it on the command 
line to make (as Joe stated) or via passing the parameter to make for 
portupgrade....although that change doesn't get saved anywhere and will 
be clobbered by the next cvsup- any clean way to avoid this?  I need to 
build apache for this system at some point, and somehow I'm not just 
seeing the defaults as likely to 'fit everyone' on that one....?

Thanks again,

Scott

>>Thanks,
>>
>>Scott
>>
>>_______________________________________________
>>freebsd-ports at freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>>    
>>