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 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

_______________________________________________
[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]"

Reply via email to