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
*** [EMAIL PROTECTED]
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, [EMAIL PROTECTED]
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
portupgradealthough 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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
