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" >> >>Received on Tue Oct 21 2003 - 20:34:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:26 UTC