Question on freeBSD (5.1-CURRENT) portupgrade of Perl
Scott Wegener, Roadster Performance
wegster at roadsterperformance.com
Tue Oct 21 22:34:30 PDT 2003
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:
>>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
>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.
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....?
>>freebsd-ports at freebsd.org mailing list
>>To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports