Re: 14-CURRENT/aarch64 build problem
On 6/8/21 3:42 PM, Juraj Lutter wrote: On 8 Jun 2021, at 21:38, bob prohaska wrote: FWIW, same problem seen here. In an added twist, git pull (hoping for a fix) fails also: root@www:/usr/src # git pull error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/legacy' From https://git.freebsd.org/src ! [new branch] vendor/openzfs/legacy -> freebsd/vendor/openzfs/legacy (unable to update local ref) error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/master' ! [new branch] vendor/openzfs/master -> freebsd/vendor/openzfs/master (unable to update local ref) error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' ! [new branch] vendor/openzfs/zfs-2.1-release -> freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) Is this a problem at my end, or the server's end? This already has been documented, as the old openzfs branch has been renamed/moved. $ git remote prune freebsd $ git pull See: https://lists.freebsd.org/archives/freebsd-git/2021-June/15.html Having pulled a completely new tree (rm -rf /usr/src/*; git clone), I get the following failure .. did I miss something? ===> cddl/lib/libicp_rescue (obj,all,install) Building /usr/obj/usr/src/amd64.amd64/cddl/lib/libicp_rescue/libicp_rescue.so.3 building shared library libicp_rescue.so.3 Building /usr/obj/usr/src/amd64.amd64/cddl/lib/libicp_rescue/_libinstall ===> cddl/lib/libspl (obj,all,install) make[4]: make[4]: don't know how to make atomic.S. Stop `assert.c' is up to date. `list.c' is up to date. `mkdirp.c' is up to date. `page.c' is up to date. `timestamp.c' is up to date. `zone.c' is up to date. `include/sys/list.h' is up to date. `include/sys/list_impl.h' is up to date. `getexecname.c' is up to date. `gethostid.c' is up to date. `getmntany.c' is up to date. `mnttab.c' is up to date. `atomic.S' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)! `afterdepend' was not built (deferred, type OP_DEPENDS|OP_NOTMAIN|OP_PHONY|OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONECYCLE)! `afterdepend' has .ORDER dependency against .depend (deferred, type OP_DEPENDS|OP_NOPATH|OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|CYCLE|DONECYCLE) `assert.o' was not built (unmade, type OP_DEPENDS|OP_NOPATH|OP_HAS_COMMANDS|OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONECYCLE)! `list.o' was not built (unmade, type OP_DEPENDS|OP_NOPATH|OP_HAS_COMMANDS|OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONECYCLE)! ` [ .. etc. .. ] imb
Re: 14-CURRENT/aarch64 build problem
> On 8 Jun 2021, at 21:38, bob prohaska wrote: > > FWIW, same problem seen here. In an added twist, git pull (hoping for > a fix) fails also: > > root@www:/usr/src # git pull > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': > 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create > 'refs/remotes/freebsd/vendor/openzfs/legacy' > From https://git.freebsd.org/src > ! [new branch] vendor/openzfs/legacy -> > freebsd/vendor/openzfs/legacy (unable to update local ref) > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': > 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create > 'refs/remotes/freebsd/vendor/openzfs/master' > ! [new branch] vendor/openzfs/master -> > freebsd/vendor/openzfs/master (unable to update local ref) > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': > 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create > 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' > ! [new branch] vendor/openzfs/zfs-2.1-release -> > freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) > > Is this a problem at my end, or the server's end? This already has been documented, as the old openzfs branch has been renamed/moved. $ git remote prune freebsd $ git pull See: https://lists.freebsd.org/archives/freebsd-git/2021-June/15.html otis — Juraj Lutter o...@freebsd.org
Re: 14-CURRENT/aarch64 build problem
On Tue, Jun 08, 2021 at 09:15:37PM +0200, Juraj Lutter wrote: > Hi, > > I???m having problem to build recent 14-CURRENT/aarch64 as of > 6d2648bcaba9b14e2f5c76680f3e7608e1f125f4: > > --- cddl/lib/libuutil__L --- > make[4]: make[4]: don't know how to make uu_dprintf.c. Stop > make[4]: make[4]: don't know how to make uu_open.c. Stop > `uu_alloc.c' is up to date. > `uu_avl.c' is up to date. > `uu_dprintf.c' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags > REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)! > ??? > > The build is performed with pristine /usr/obj > FWIW, same problem seen here. In an added twist, git pull (hoping for a fix) fails also: root@www:/usr/src # git pull error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/legacy' >From https://git.freebsd.org/src ! [new branch] vendor/openzfs/legacy -> freebsd/vendor/openzfs/legacy (unable to update local ref) error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/master' ! [new branch] vendor/openzfs/master -> freebsd/vendor/openzfs/master (unable to update local ref) error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' ! [new branch] vendor/openzfs/zfs-2.1-release -> freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) Is this a problem at my end, or the server's end? Thanks for reading, bob prohaska
14-CURRENT/aarch64 build problem
Hi, I’m having problem to build recent 14-CURRENT/aarch64 as of 6d2648bcaba9b14e2f5c76680f3e7608e1f125f4: --- cddl/lib/libuutil__L --- make[4]: make[4]: don't know how to make uu_dprintf.c. Stop make[4]: make[4]: don't know how to make uu_open.c. Stop `uu_alloc.c' is up to date. `uu_avl.c' is up to date. `uu_dprintf.c' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)! … The build is performed with pristine /usr/obj Any hints, please? Thanks otis — Juraj Lutter o...@freebsd.org
Re: geeqie, and neverball build problem on 13-current
On 2020-09-24 11:52, Stefan Esser wrote: Am 24.09.20 um 11:24 schrieb Niclas Zeising: On 2020-09-24 11:17, monochrome wrote: Not sure how long this has been a problem, I noticed with the new version of geeqie (geeqie-devel builds fine) and found the neverball problem when rebuilding all packages to investigate. neverball output changes with consecutive build attempts, geeqie does not. This is related to the update of llvm to 11. With this update, builds are by default using -fno-common, which means global variables cannot exist in multiple places. gcc 10 has the same default. A quick fix is to add -fcommon to CFLAGS, but the proper fix is to update the application source to only have the variable in one place. This was very easy to fix (like most of the ports affected by the -fno-common issue). The port is updated (r549911) and packages will appear in due time. Great! Thanks for doing the work! Regards -- Niclas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: geeqie, and neverball build problem on 13-current
Am 24.09.20 um 11:24 schrieb Niclas Zeising: On 2020-09-24 11:17, monochrome wrote: Not sure how long this has been a problem, I noticed with the new version of geeqie (geeqie-devel builds fine) and found the neverball problem when rebuilding all packages to investigate. neverball output changes with consecutive build attempts, geeqie does not. This is related to the update of llvm to 11. With this update, builds are by default using -fno-common, which means global variables cannot exist in multiple places. gcc 10 has the same default. A quick fix is to add -fcommon to CFLAGS, but the proper fix is to update the application source to only have the variable in one place. This was very easy to fix (like most of the ports affected by the -fno-common issue). The port is updated (r549911) and packages will appear in due time. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: geeqie, and neverball build problem on 13-current
On 2020-09-24 11:17, monochrome wrote: Not sure how long this has been a problem, I noticed with the new version of geeqie (geeqie-devel builds fine) and found the neverball problem when rebuilding all packages to investigate. neverball output changes with consecutive build attempts, geeqie does not. This is related to the update of llvm to 11. With this update, builds are by default using -fno-common, which means global variables cannot exist in multiple places. gcc 10 has the same default. A quick fix is to add -fcommon to CFLAGS, but the proper fix is to update the application source to only have the variable in one place. Regards -- Niclas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
geeqie, and neverball build problem on 13-current
Not sure how long this has been a problem, I noticed with the new version of geeqie (geeqie-devel builds fine) and found the neverball problem when rebuilding all packages to investigate. neverball output changes with consecutive build attempts, geeqie does not. --- geeqie output: first some of these: /usr/local/include/gtk-2.0/gtk/gtktooltips.h:73:3: warning: 'GTimeVal' is deprecated: Use 'GDateTime' instead [-Wdeprecated-declarations] then c++ -I/usr/local/include -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -D_THREAD_SAFE -pthread -I/usr/local/include -I/usr/local/include-I/usr/local/include/lua53 -I.. -I.. -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fstack-protector-strong -o geeqie ui_bookmark.o ui_fileops.o ui_help.o ui_menu.o ui_misc.o ui_pathsel.o ui_spinner.o ui_tabcomp.o ui_tree_edit.o ui_utildlg.o pan-view/pan-calendar.o pan-view/pan-folder.o pan-view/pan-grid.o pan-view/pan-item.o pan-view/pan-timeline.o pan-view/pan-util.o pan-view/pan-view.o pan-view/pan-view-filter.o pan-view/pan-view-search.o view_file/view_file.o view_file/view_file_icon.o view_file/view_file_list.o advanced_exif.o bar.o bar_comment.o bar_gps.o bar_histogram.o bar_keywords.o bar_exif.o bar_sort.o cache.o cache-loader.o cache_maint.o cellrenderericon.o collect.o collect-dlg.o collect-io.o collect-table.o color-man.o compat.o debug.o desktop_file.o dnd.o dupe.o editors.o exif.o exif-common.o exiv2.o filecache.o filedata.o filefilter.o gq-marshal.o format_canon.o format_fuji.o format_nikon.o format_olympus.o format_raw.o fullscreen.o histogram.o history_list.o image.o image-load.o image_load_gdk.o image_load_jpeg.o image_load_tiff.o image_load_dds.o image_load_collection.o image_load_pdf.o image_load_ffmpegthumbnailer.o image-overlay.o img-view.o jpeg_parser.o layout.o layout_config.o layout_image.o layout_util.o keymap_template.o lirc.o logwindow.o main.o md5-util.o menu.o metadata.o misc.o options.o osd.o pixbuf-renderer.o renderer-tiles.o renderer-clutter.o pixbuf_util.o preferences.o print.o remote.o rcfile.o search.o secure_save.o shortcuts.o similar.o slideshow.o thumb.o thumb_standard.o toolbar.o trash.o uri_utils.o utilops.o view_dir.o view_dir_list.o view_dir_tree.o window.o lua.o zonedetect.o -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lpthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -lfreetype -L/usr/local/lib -lgthread-2.0 -pthread -lglib-2.0 -lintl -lintl -ljpeg -ltiff -L/usr/local/lib -llcms2 -L/usr/local/lib -lexiv2-L/usr/local/lib -llua-5.3 -lm -L/usr/local/lib ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_count) >>> defined at advanced_exif.c >>>advanced_exif.o:(.rodata+0x0) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_list) >>> defined at advanced_exif.c >>>advanced_exif.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_count) >>> defined at bar.c >>>bar.o:(.rodata+0x180) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_list) >>> defined at bar.c >>>bar.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_count) >>> defined at bar_exif.c >>>bar_exif.o:(.rodata+0x0) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_list) >>> defined at bar_exif.c >>>bar_exif.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_count) >>> defined at options.c >>>options.o:(.rodata+0x0) ld: error: duplicate symbol: bar_exif_key_list >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_list) >>> defined at options.c >>>options.o:(.bss+0x0) ld: error: duplicate symbol: bar_exif_key_count >>> defined at pan-view.c >>>pan-view/pan-view.o:(bar_exif_key_count) >>> defined at preferences.c >>>preferences.o:(.rodata+0x30) ld: error: duplicate
Re: head -r333974 fix-to-the-build exposes another breaks-the-build problem in top (at least for gcc based builds)
On 21 May 2018 at 18:06, Mark Millard wrote: > On 2018-May-21, at 5:46 PM, Mark Millard wrote: > I should have been explicit that the material is from > ci.freebsd.org . Your email seems to always be marked as spam by my MUA even though SPF, DKIM, and DMARC pass. Apologies if you've sent me other mail I've missed. > For reference, the gcc based builds seem to be: > (all but the last being gcc 4.2.1 based if I > undertand right) FWIW believe these are fixed now. At least, they do not fail locally on "make universe" on top(1). -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r333974 fix-to-the-build exposes another breaks-the-build problem in top (at least for gcc based builds)
On 2018-May-21, at 5:46 PM, Mark Millard wrote: > FreeBSD-head-amd64-gcc (based on a more modern gcc) reports a > more explicit error for -r333974 and later: > > --- all_subdir_usr.bin --- > /workspace/src/usr.bin/top/commands.c:132:1: error: function declaration > isn't a prototype [-Werror=strict-prototypes] > scanint(str, intp) > ^~~ > > The older gcc 4.2.1 builds report: > > --- all_subdir_usr.bin/top --- > cc1: warnings being treated as errors > /usr/src/usr.bin/top/commands.c:134: warning: function declaration isn't a > prototype > *** [commands.o] Error code 1 > > make[4]: stopped in /usr/src/usr.bin/top > 1 error I should have been explicit that the material is from ci.freebsd.org . For reference, the gcc based builds seem to be: (all but the last being gcc 4.2.1 based if I undertand right) FreeBSD-head-mips-build FreeBSD-head-mips64-build FreeBSD-head-powerpc-build FreeBSD-head-powerpc64-build FreeBSD-head-powerpcspe-build FreeBSD-head-sparc64-build FreeBSD-head-amd64-gcc So those are what I'm reporting as having broken builds for the specific issue. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
head -r333974 fix-to-the-build exposes another breaks-the-build problem in top (at least for gcc based builds)
FreeBSD-head-amd64-gcc (based on a more modern gcc) reports a more explicit error for -r333974 and later: --- all_subdir_usr.bin --- /workspace/src/usr.bin/top/commands.c:132:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] scanint(str, intp) ^~~ The older gcc 4.2.1 builds report: --- all_subdir_usr.bin/top --- cc1: warnings being treated as errors /usr/src/usr.bin/top/commands.c:134: warning: function declaration isn't a prototype *** [commands.o] Error code 1 make[4]: stopped in /usr/src/usr.bin/top 1 error === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Revision: 329797 kernel build problem
When trying to build the kernel, I get:
--- all_subdir_linux ---
/usr/src/sys/amd64/linux32/linux32_dummy.c:1:5: error: unknown type name
'sys'
--- linux_fork.o ---
ctfconvert -L VERSION -g linux_fork.o
--- nsprepkg.o ---
cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe
-fno-strict-aliasing?? -g -nostdinc?? -I. -I/usr/src/sys
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h?? -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -MD?? -MF.depend.nsprepkg.o -MTnsprepkg.o
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float??
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-error-address-of-packed-member?? -mno-aes -mno-avx??
-std=iso9899:1999 -Werror??
/usr/src/sys/contrib/dev/acpica/components/namespace/nsprepkg.c
--- modules-all ---
--- linux32_dummy.o ---
?? sys/sys/sysent.2
?? ^
/usr/src/sys/amd64/linux32/linux32_dummy.c:1:8: error: expected
identifier or '('
?? sys/sys/sysent.2
^
--- all_subdir_linux64 ---
--- assym.s ---
sh /usr/src/sys/kern/genassym.sh genassym.o > assym.s
--- all_subdir_libalias ---
--- alias_smedia.o ---
cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin?? -O2 -pipe??
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. -I/usr/src/sys
-fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/amd64.amd64/sys/GENERIC -MD??
-MF.depend.alias_smedia.o -MTalias_smedia.o -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float??
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-error-address-of-packed-member?? -mno-aes -mno-avx??
-std=iso9899:1999 -c /usr/src/sys/netinet/libalias/alias_smedia.c -o
alias_smedia.o
--- all_subdir_linux64 ---
--- linux_genassym.o ---
cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. -I/usr/src/sys
-g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/amd64.amd64/sys/GENERIC -MD
-MF.depend.linux_genassym.o -MTlinux_genassym.o -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
-gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-error-unused-function
-Wno-error-pointer-sign -Wno-error-shift-negative-value
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999
/usr/src/sys/amd64/linux/linux_genassym.c
--- all_subdir_linux ---
2 errors generated.
--- all_subdir_linux64 ---
--- linux_fork.o ---
cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin?? -O2 -pipe??
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/amd64.amd64/sys/GENERIC/opt_global.h -I. -I/usr/src/sys
-fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/amd64.amd64/sys/GENERIC -MD??
-MF.depend.linux_fork.o -MTlinux_fork.o -mcmodel=kernel -mno-red-zone
-mno-mmx -mno-sse -msoft-float?? -fno-asynchronous-unwind-tables
-ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
port cimg build problem
When I try to install the cimg ports I get this errors root@valfenda:/usr/ports/graphics/cimg # make install clean ===> Building for cimg-1.5.6_1,3 gmake[1]: Entrando no diretório `/usr/ports/graphics/cimg/work/CImg-1.5.6/examples' gmake[2]: Entrando no diretório `/usr/ports/graphics/cimg/work/CImg-1.5.6/examples' ** Compiling 'CImg_demo (1.5.6)' with 'g++46' g++46 -o CImg_demo CImg_demo.cpp -I.. -Wall -W -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -fno-tree-pre -Dcimg_use_vt100 -I/usr/local/include -Dcimg_use_xrandr -Dcimg_use_tiff -Dcimg_use_openexr -I//usr/local/include/OpenEXR -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_zlib -Dcimg_use_opencv -I/usr/local/include/opencv -Dcimg_use_magick -I/usr/local/include/GraphicsMagick -O2 -pipe -DPNG_DEPSTRUCT= -fno-strict-aliasing -Dcimg_use_lapack -Dcimg_use_fftw3 -pthread -Wl,-rpath=/usr/local/lib/gcc46 -lm -lm -L/usr/local/lib -lX11 -lXrandr -ltiff -lIlmImf -lHalf -lpng -lz -ljpeg -lz -lopencv_legacy -lopencv_highgui -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lGraphicsMagick++ -lGraphicsMagick -ljbig -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng -lfpx -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm -L/usr/local/lib -llapack -lblas -lfftw3 ** Compiling 'captcha (1.5.6)' with 'g++46' g++46 -o captcha captcha.cpp -I.. -Wall -W -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -fno-tree-pre -Dcimg_use_vt100 -I/usr/local/include -Dcimg_use_xrandr -Dcimg_use_tiff -Dcimg_use_openexr -I//usr/local/include/OpenEXR -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_zlib -Dcimg_use_opencv -I/usr/local/include/opencv -Dcimg_use_magick -I/usr/local/include/GraphicsMagick -O2 -pipe -DPNG_DEPSTRUCT= -fno-strict-aliasing -Dcimg_use_lapack -Dcimg_use_fftw3 -pthread -Wl,-rpath=/usr/local/lib/gcc46 -lm -lm -L/usr/local/lib -lX11 -lXrandr -ltiff -lIlmImf -lHalf -lpng -lz -ljpeg -lz -lopencv_legacy -lopencv_highgui -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -lGraphicsMagick++ -lGraphicsMagick -ljbig -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng -lfpx -lwmflite -lXext -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lm -L/usr/local/lib -llapack -lblas -lfftw3 /tmp//ccda87Cc.o: In function `cimg_library::CImg::save_magick(char const*, unsigned int) const': captcha.cpp:(.text._ZNK12cimg_library4CImgIhE11save_magickEPKcj[cimg_library::CImg::save_magick(char const*, unsigned int) const]+0x29b): undefined reference to `Magick::Image::write(std::basic_string, std::allocator > const&)' collect2: ld returned 1 exit status gmake[2]: ** [captcha] Erro 1 gmake[2]: *** Esperando que os outros processos terminem /tmp//ccFOT8wN.o: In function `cimg_library::CImg::save_magick(char const*, unsigned int) const': CImg_demo.cpp:(.text._ZNK12cimg_library4CImgIhE11save_magickEPKcj[cimg_library::CImg::save_magick(char const*, unsigned int) const]+0x27b): undefined reference to `Magick::Image::write(std::basic_string, std::allocator > const&)' collect2: ld returned 1 exit status gmake[2]: ** [CImg_demo] Erro 1 gmake[2]: Saindo do diretório `/usr/ports/graphics/cimg/work/CImg-1.5.6/examples' gmake[1]: ** [Mlinux] Erro 2 gmake[1]: Saindo do diretório `/usr/ports/graphics/cimg/work/CImg-1.5.6/examples' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/graphics/cimg root@valfenda:/usr/ports/graphics/cimg # ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Newbie build problem
Hi, I've been R-ing the FWP but haven't had any luck so far: Specifically, when I try to make buildworld I get: ===> usr.bin/yacc /shared/FreeBSD-current/shared/FreeBSD-current/usr/src/usr.bin/yacc created for /shared/FreeBSD-current/usr/src/usr.bin/yacc sh /shared/FreeBSD-current/usr/src/tools/install.sh -s -o root -g wheel -m 555 yacc /shared/FreeBSD-current/usr/bin sh /shared/FreeBSD-current/usr/src/tools/install.sh -o root -g wheel -m 555 yy fix.sh /shared/FreeBSD-current/usr/bin/yyfix install: /shared/FreeBSD-current/usr/bin/yyfix: Not a directory *** Error code 71 Stop in /shared/FreeBSD-current/usr/src/usr.bin/yacc. *** Error code 1 Stop in /shared/FreeBSD-current/usr/src. *** Error code 1 Stop in /shared/FreeBSD-current/usr/src. *** Error code 1 Stop in /shared/FreeBSD-current/usr/src. This is with the tree cvsup'd into /shared/FreeBSD-current. Am I supposed to create the bin directory by hand? I thought the makefile would build directories it needs. My make.conf looks like this: # -- use.perl generated deltas -- # # Created: Thu Mar 6 04:17:57 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo MAKEOBJDIRPREFIX=/shared/FreeBSD-current NOGAMES=true Any pointers would be helpful. I've spent a lot of time on this webpage: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html But it seems to be out of date as some files on it don't exist in 5.0. Thanks for any help! Gordon = -- Gordon Zaft [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.0 kernel build problem
I'm trying to upgrade from 4.7-RELEASE-P1 to 5.0-RELEASE but I consistently get the same error when trying to compile a kernel (GENERIC or otherwise): linking kernel textdata bss dec hex filename 3043330 343744 277828 3664902 37ec06 kernel cd /usr/src/sys/modules ; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/GERTRUDE/modules KMODDIR=/boot/kernel MACHINE=i386 make all ===> accf_data make: don't know how to make @/sys/inttypes.h. Stop I feel silly not being able to find the problem. This is after a buildworld and comes late in the process after: env -i make buildkernel KERNCONF=GERTRUDE Attempting to build GENERIC results in the same failure. thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange cross-build problem and something with GEOM
Replying to my own message:
---
> 2 60g drives, ad0 has a complete -stable on it, ad1 current.
>
> First, GEOM:
> On trying to do "boot0cfg -s1 /dev/ad0" to get back to booting stable,
> to try to recover from the next problem, I get "operation not permitted".
> This didn't happen with NO_GEOM... Is there a new device name to use
> here?
>
> Unfortunately now I can't recover from the next problem without taking
> a drive (the system in question is remote; fortunately only a few miles).
>
> ====== Part 2 =
> Now for the cross-build problem:
>
> On building both stable and current under stable, I get a crippled cpp
> in current; it can't do *anything* right, and gets various errors in
> various situations.
> with source:
>
> gooney# cat hello.c
> #include
>
> main()
> {
> printf("Hello, World!\n");
> }
> --
> gooney# cc -o hello hello.c
> hello.c:1: undefined or invalid # directive
>
> If I add a comment in the first line, I get:
>
> gooney# cc -o hello hello.c
> hello.c:1: syntax error before `/'
>
> and the make world under current dies in the very first mkdep, before the
> first compile, with another cpp error:
> --
Answer is: There was some cruft left over in /usr/bin; copies of
cc1 and friends, and cpp0. Apparently the copies in /usr/libexec
get ignored if the progs exist in /usr/bin. Cleaning those (and
a couple of old copies of perl too :-) out fixed the problem.
Now to get it so boot0cfg works under GEOM...
-- Pete
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Strange cross-build problem and something with GEOM
On Tue, Nov 19, 2002 at 09:35:59AM -0800, Pete Carah wrote:
> This is, for a change, not relative to my Vaio (which still won't boot
> current, in spite of various improvements apparent in boot -v).
>
> Hardware is a Supermicro P3TDDE (SMP P3-1G, via chipset).
> 2 60g drives, ad0 has a complete -stable on it, ad1 current.
>
> First, GEOM:
> On trying to do "boot0cfg -s1 /dev/ad0" to get back to booting stable,
> to try to recover from the next problem, I get "operation not permitted".
> This didn't happen with NO_GEOM... Is there a new device name to use
> here?
>
> Unfortunately now I can't recover from the next problem without taking
> a drive (the system in question is remote; fortunately only a few miles).
>
> == Part 2 =
> Now for the cross-build problem:
>
> On building both stable and current under stable, I get a crippled cpp
> in current; it can't do *anything* right, and gets various errors in
> various situations.
> with source:
>
> gooney# cat hello.c
> #include
>
> main()
> {
> printf("Hello, World!\n");
> }
> --
> gooney# cc -o hello hello.c
> hello.c:1: undefined or invalid # directive
>
> If I add a comment in the first line, I get:
>
> gooney# cc -o hello hello.c
> hello.c:1: syntax error before `/'
>
> and the make world under current dies in the very first mkdep, before the
> first compile, with another cpp error:
> --
> mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c
> /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=unix'
> /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=bsd'
> /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=FreeBSD'
> /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A cpu=i386'
> /usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A machine=i386'
> mkdep: compile failed
> *** Error code 1
>
> Stop in /usr/src/games/fortune/strfile.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
> ---
>
> Anyhow, I know from other experience that this is not a fundamental
> problem with building gcc 3.x under fbsd 4.x; if the gnu build system
> is used the result works fine. Something is wrong in the 5.x cross-build
> context that results in a brain-dead cpp. All else "appears" OK, though
> one wonders.
>
I do cross-build the 5.0-CURRENT portion of my dual -STABLE/-CURRENT
box on a day basis under -STABLE, last time this night:
# uname -v
FreeBSD 5.0-CURRENT #0: Tue Nov 19 05:48:00 EET 2002
[EMAIL PROTECTED]:/usr/obj/CURRENT/usr/src/sys/PERL
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg46933/pgp0.pgp
Description: PGP signature
Strange cross-build problem and something with GEOM
This is, for a change, not relative to my Vaio (which still won't boot
current, in spite of various improvements apparent in boot -v).
Hardware is a Supermicro P3TDDE (SMP P3-1G, via chipset).
2 60g drives, ad0 has a complete -stable on it, ad1 current.
First, GEOM:
On trying to do "boot0cfg -s1 /dev/ad0" to get back to booting stable,
to try to recover from the next problem, I get "operation not permitted".
This didn't happen with NO_GEOM... Is there a new device name to use
here?
Unfortunately now I can't recover from the next problem without taking
a drive (the system in question is remote; fortunately only a few miles).
== Part 2 =========
Now for the cross-build problem:
On building both stable and current under stable, I get a crippled cpp
in current; it can't do *anything* right, and gets various errors in
various situations.
with source:
gooney# cat hello.c
#include
main()
{
printf("Hello, World!\n");
}
--
gooney# cc -o hello hello.c
hello.c:1: undefined or invalid # directive
If I add a comment in the first line, I get:
gooney# cc -o hello hello.c
hello.c:1: syntax error before `/'
and the make world under current dies in the very first mkdep, before the
first compile, with another cpp error:
--
mkdep -f .depend -a /usr/src/games/fortune/strfile/strfile.c
/usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=unix'
/usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=bsd'
/usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A system=FreeBSD'
/usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A cpu=i386'
/usr/src/games/fortune/strfile/strfile.c:0: malformed option `-A machine=i386'
mkdep: compile failed
*** Error code 1
Stop in /usr/src/games/fortune/strfile.
*** Error code 1
Stop in /usr/src.
*** Error code 1
---
Anyhow, I know from other experience that this is not a fundamental
problem with building gcc 3.x under fbsd 4.x; if the gnu build system
is used the result works fine. Something is wrong in the 5.x cross-build
context that results in a brain-dead cpp. All else "appears" OK, though
one wonders.
-- Pete
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
XFree86-4-libraries build problem on -current
i can't install XFree86-4-libraries using -current cvsupped and copmiled a day ago. it builds fine, but the installations fails with the following diags: LD_LIBRARY_PATH=../../../../../exports/lib cc -c -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../../../exports/include/X11 -I../../../../../include/extensions -I../../../../../extras/Mesa/src/OSmesa -I../../../../../extras/Mesa/src -I../../../../../extras/Mesa/include -I../../../../.. -I../../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL ../../../../../lib/GL/mesa/src/translate.c -o unshared/../../../../../lib/GL/mesa/src/translate.o *** Error code 1 Stop in /garbage/ports/x11/XFree86-4-libraries/work/xc/lib/GL/mesa/src/OSmesa. *** Error code 1 Stop in /garbage/ports/x11/XFree86-4-libraries/work/xc/lib/GL. *** Error code 1 Stop in /garbage/ports/x11/XFree86-4-libraries/work/xc/lib. *** Error code 1 Stop in /garbage/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /garbage/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /garbage/ports/x11/XFree86-4-libraries. *** Error code 1 i have seen an 'unofficial' patch announce (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=7709+0+current/freebsd-current), but i couldn't find the exact fix. could you please re-post it or commit necessary changes right into the port? thanks in advance. -- sincerely, ilya naumov (at work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup-devel port build problem (pm3-base)
John Polstra <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Brian Somers <[EMAIL PROTECTED]> wrote:
> > I sent John Polstra a similar patch some time ago Any news about
> > getting this committed John (P) ?
>
> There is already an open PR with a patch. I think Mark Murray is
> working on committing it. I don't have the systems needed to test
> it myself at the moment.
Mark, any news on this ? FWIW, I've attached the patch that makes
things work here.
> John
> --
> John Polstra
> John D. Polstra & Co., Inc.Seattle, Washington USA
> "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
Cheers.
--
Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]>
http://www.freebsd-services.com/
Don't _EVER_ lose your sense of humour !
Index: patch-l1
===
RCS file: /home/ncvs/ports/lang/pm3-base/files/patch-l1,v
retrieving revision 1.1
diff -u -r1.1 patch-l1
--- patch-l121 Jul 2001 21:07:55 - 1.1
+++ patch-l111 Oct 2001 00:01:13 -
@@ -1,6 +1,18 @@
libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c.old Thu Jun 1 02:54:33 2000
-+++ libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c Tue Jun 12 14:07:31 2001
-@@ -693,7 +693,9 @@
+--- libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c.orig Thu Oct 11 00:59:24 2001
libs/m3core/src/runtime/FreeBSD4/RTHeapDepC.c Thu Oct 11 01:00:50 2001
+@@ -98,7 +98,11 @@
+ #include
+ #include
+ #include
++#if __FreeBSD_version >= 500024
++#include
++#else
+ #include
++#endif
+ #include
+ #endif
+
+@@ -693,7 +697,9 @@
void *data;
{ int result;
struct ufs_args *u_data;
@@ -10,7 +22,7 @@
struct nfs_args *n_data;
ENTER_CRITICAL;
-@@ -704,11 +706,13 @@
+@@ -704,11 +710,13 @@
MAKE_READABLE(u_data);
MAKE_READABLE(u_data->fspec);
result = syscall(SYS_mount, type, dir, flags, data);
Index: patch-l2
===
RCS file: /home/ncvs/ports/lang/pm3-base/files/patch-l2,v
retrieving revision 1.2
diff -u -r1.2 patch-l2
--- patch-l210 Sep 2001 21:37:26 - 1.2
+++ patch-l211 Oct 2001 00:04:58 -
@@ -1,6 +1,18 @@
libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.c.old Thu Jun 1 02:54:33 2000
-+++ libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.c Tue Jun 12 14:07:31 2001
-@@ -693,7 +693,9 @@
+--- libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.c.orig Wed May 31 18:54:24
+2000
libs/m3core/src/runtime/FBSD_ALPHA/RTHeapDepC.cThu Oct 11 00:29:03 2001
+@@ -98,7 +98,11 @@
+ #include
+ #include
+ #include
++#if __FreeBSD_version >= 500024
++#include
++#else
+ #include
++#endif
+ #include
+ #endif
+
+@@ -693,7 +697,9 @@
void *data;
{ int result;
struct ufs_args *u_data;
@@ -10,7 +22,7 @@
struct nfs_args *n_data;
ENTER_CRITICAL;
-@@ -704,11 +706,13 @@
+@@ -704,11 +710,13 @@
MAKE_READABLE(u_data);
MAKE_READABLE(u_data->fspec);
result = syscall(SYS_mount, type, dir, flags, data);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvsup-devel port build problem (pm3-base)
In article <[EMAIL PROTECTED]>, Brian Somers <[EMAIL PROTECTED]> wrote: > I sent John Polstra a similar patch some time ago Any news about > getting this committed John (P) ? There is already an open PR with a patch. I think Mark Murray is working on committing it. I don't have the systems needed to test it myself at the moment. John -- John Polstra John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup-devel port build problem (pm3-base)
I sent John Polstra a similar patch some time ago Any news about getting this committed John (P) ? > Hi, > > I ran into some problems building the cvsup-devel > port. In one of it's dependants, the c file is attempting > to include which is nolonger valid. > > /usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4/RTHeapDepC.c > > As a quick fix I symlinked nfs.h -> ../nfsclient/nfs.h > which allowed the compile to complete. > > The following more generic/correct fix could probably > be dropped into the files directory as patch-XX: > > --- RTHeapDepC.c.orig Mon Nov 19 00:27:30 2001 > +++ RTHeapDepC.cMon Nov 19 00:28:21 2001 > @@ -98,7 +98,11 @@ > #include > #include > #include > +#if __FreeBSD__ >= 5 > +#include > +#else > #include > +#endif > #include > #endif > > > -John > > ps: I also ran into problems with libutil.h but I haven't > determined where the actual problem is coming from. > Copying /usr/src/lib/libutil/libutil.h to /usr/include > avoids the immediate problem. -- Brian <[EMAIL PROTECTED]><[EMAIL PROTECTED]> http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvsup-devel port build problem (pm3-base)
Hi, I ran into some problems building the cvsup-devel port. In one of it's dependants, the c file is attempting to include which is nolonger valid. /usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4/RTHeapDepC.c As a quick fix I symlinked nfs.h -> ../nfsclient/nfs.h which allowed the compile to complete. The following more generic/correct fix could probably be dropped into the files directory as patch-XX: --- RTHeapDepC.c.orig Mon Nov 19 00:27:30 2001 +++ RTHeapDepC.cMon Nov 19 00:28:21 2001 @@ -98,7 +98,11 @@ #include #include #include +#if __FreeBSD__ >= 5 +#include +#else #include +#endif #include #endif -John ps: I also ran into problems with libutil.h but I haven't determined where the actual problem is coming from. Copying /usr/src/lib/libutil/libutil.h to /usr/include avoids the immediate problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
On Mon, 17 Sep 2001, Ruslan Ermilov wrote:
> On Sat, Sep 15, 2001 at 03:57:26AM +1000, Bruce Evans wrote:
> > On Wed, 5 Sep 2001, Ruslan Ermilov wrote:
> >
> > > On Wed, Sep 05, 2001 at 09:44:05PM +1000, Bruce Evans wrote:
> > > [...]
> > > What do I hear?! Are we required to support non-FreeBSD hosts at the
> > > Makefile level? That would be too conservative, and is already broken
> > > in many other ways.
> > >
> > > > It is unreasonable to expect the target source strtofflags.c to be
> > > > compilable in the host environment.
> > > >
> > > But we can at least try (with high probability of success) -- this is
> > > better than the current breakage Jordan observes.
> >
> > I think it's easier to make a fairly general case work than fix special
> > cases as they turn up.
> >
> But we only need to "fix" these special (bootstrapping) cases.
By "special cases", I meant all problems that turn up for FreeBSD-u.v.w
hosts and FreeBSD-x.y.z targets (u >= 2, x >= 2). There will be about as
many of them as for the more general case of a general POSIX.[1-2]-1990ish
host and a FreeBSD-x.y.z target.
> > > > The correct fix is to not support file flags in the bootstrap
> > > > version of install.
> > > >
> > > But we now always bootstrap install(1). Not including support for
> > > file flags here would mean "no support for file flags during the
> > > installworld".
> >
> > That's certainly a problem. I still don't see the point of the runtime
> > test to avoid using strtofflags.c. strttofflags.c is just as portable as
> > the xinstall sources (modulo the dependency on declaring the
> > things in it, if WARNS is turned on).
> >
> Probably because you build your world static? :-) In a non-static
> case (like for the normal ``make buildworld''), strtofflags.c is the
> version that is getting compiled into, if used unconditionally.
Nah, the static case has better error checking, so it is just more
likely to break if strtofflags is in libc.a and is misimplemented so
that it conflicts with the local version :-). Tools should be linked
static anyway, if possible. (This may not be possible. A POSIX or
even a FreeBSD-2+ host might not have any static libraries. Or it
might not have any dynamic libraries. A general POSIX host might not
even have a -static compiler flag to control this. However, the details
can be hidden in the handling of the NOSHARED flag. buildworld should
simply set this flag for tools like it used to.)
> If there would be a way to distinguish before bootstrapping and normal
> builds, I would definitely agree.
There is the (slightly misnamed) "WORLD" flag. mtree/Makefile uses this
flag, but setting of it is broken. ISTR that there used to be a flag
that said that the build-tools target is being built.
>
> Something as simple as this might work as well:
>
> Index: Makefile.inc1
> ===
> RCS file: /home/ncvs/src/Makefile.inc1,v
> retrieving revision 1.215
> diff -u -r1.215 Makefile.inc1
> --- Makefile.inc1 2001/08/29 09:11:03 1.215
> +++ Makefile.inc1 2001/09/17 07:13:50
> @@ -180,7 +180,7 @@
> # bootstrap-tool stage
> BMAKEENV=${BOOTSTRAPENV}
> BMAKE= ${BMAKEENV} ${MAKE} -f Makefile.inc1 -DNOHTML -DNOINFO \
> - -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED
> + -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DBOOTSTRAPPING
>
> # build-tool stage
> TMAKEENV=MAKEOBJDIRPREFIX=${OBJTREE} \
Hmm, we already use NOSHARED for BMAKE and XMAKE. We just don't use it
(explicitly?) for TMAKE (and of course for non-tools). My version uses
-DNOSHARED -DWORLD explicitly for BMAKE, TMAKE and XMAKE.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
On Sat, Sep 15, 2001 at 03:57:26AM +1000, Bruce Evans wrote:
> On Wed, 5 Sep 2001, Ruslan Ermilov wrote:
>
> > On Wed, Sep 05, 2001 at 09:44:05PM +1000, Bruce Evans wrote:
> > [...]
> > > > Index: Makefile
> > > > ===
> > > > RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> > > > retrieving revision 1.15
> > > > diff -u -r1.15 Makefile
> > > > --- Makefile2001/04/02 11:54:59 1.15
> > > > +++ Makefile2001/09/04 08:11:52
> > > > @@ -3,6 +3,22 @@
> > > >
> > > > PROG= xinstall
> > > > PROGNAME= install
> > > > +SRCS= xinstall.c
> > > > MAN= install.1
> > > > +
> > > > +# Get __FreeBSD_version
> > > > +.if !defined(OSVERSION)
> > > > +.if exists(/sbin/sysctl)
> > > > +OSVERSION!=/sbin/sysctl -n kern.osreldate
> > > > +.else
> > > > +OSVERSION!=/usr/sbin/sysctl -n kern.osreldate
> > > > +.endif
> > > > +.endif
> > > > +
> > > > +.if ${OSVERSION} < 400021 || \
> > > > +${OSVERSION} >= 50 && ${OSVERSION} < 57
> > > > +.PATH: ${.CURDIR}/../../lib/libc/gen
> > > > +SRCS+= strtofflags.c
> > > > +.endif
> > > >
> > > > .include
> > >
> > > Ugh. This is even worse than using __FreeBSD_version. It is broken
> > > for non-FreeBSD hosts. Hmm, this case is broken in my version too.
> > > Non-FreeBSD hosts might not have have FreeBSD file flags, so they might
> > > not have the definitions of the magic numbers necessary for strtofflags.c
> > > to compile; they might not even have the necessary headers.
> > >
> > What do I hear?! Are we required to support non-FreeBSD hosts at the
> > Makefile level? That would be too conservative, and is already broken
> > in many other ways.
> >
> > > It is unreasonable to expect the target source strtofflags.c to be
> > > compilable in the host environment.
> > >
> > But we can at least try (with high probability of success) -- this is
> > better than the current breakage Jordan observes.
>
> I think it's easier to make a fairly general case work than fix special
> cases as they turn up.
>
But we only need to "fix" these special (bootstrapping) cases.
> > > The correct fix is to not support file flags in the bootstrap
> > > version of install.
> > >
> > But we now always bootstrap install(1). Not including support for
> > file flags here would mean "no support for file flags during the
> > installworld".
>
> That's certainly a problem. I still don't see the point of the runtime
> test to avoid using strtofflags.c. strttofflags.c is just as portable as
> the xinstall sources (modulo the dependency on declaring the
> things in it, if WARNS is turned on).
>
Probably because you build your world static? :-) In a non-static
case (like for the normal ``make buildworld''), strtofflags.c is the
version that is getting compiled into, if used unconditionally.
If there would be a way to distinguish before bootstrapping and normal
builds, I would definitely agree.
Something as simple as this might work as well:
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.215
diff -u -r1.215 Makefile.inc1
--- Makefile.inc1 2001/08/29 09:11:03 1.215
+++ Makefile.inc1 2001/09/17 07:13:50
@@ -180,7 +180,7 @@
# bootstrap-tool stage
BMAKEENV= ${BOOTSTRAPENV}
BMAKE= ${BMAKEENV} ${MAKE} -f Makefile.inc1 -DNOHTML -DNOINFO \
- -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED
+ -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DBOOTSTRAPPING
# build-tool stage
TMAKEENV= MAKEOBJDIRPREFIX=${OBJTREE} \
Index: usr.bin/xinstall/Makefile
===
RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- usr.bin/xinstall/Makefile 2001/04/02 11:54:59 1.15
+++ usr.bin/xinstall/Makefile 2001/09/17 07:13:50
@@ -3,6 +3,12 @@
PROG= xinstall
PROGNAME= install
+SRCS= xinstall.c
MAN= install.1
+
+.if defined(BOOTSTRAPPING)
+.PATH: ${.CURDIR}/../../lib/libc/gen
+SRCS+= strtofflags.c
+.endif
.include
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
On Wed, 5 Sep 2001, Ruslan Ermilov wrote:
> On Wed, Sep 05, 2001 at 09:44:05PM +1000, Bruce Evans wrote:
> [...]
> > > Index: Makefile
> > > ===
> > > RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> > > retrieving revision 1.15
> > > diff -u -r1.15 Makefile
> > > --- Makefile 2001/04/02 11:54:59 1.15
> > > +++ Makefile 2001/09/04 08:11:52
> > > @@ -3,6 +3,22 @@
> > >
> > > PROG=xinstall
> > > PROGNAME=install
> > > +SRCS=xinstall.c
> > > MAN= install.1
> > > +
> > > +# Get __FreeBSD_version
> > > +.if !defined(OSVERSION)
> > > +.if exists(/sbin/sysctl)
> > > +OSVERSION!= /sbin/sysctl -n kern.osreldate
> > > +.else
> > > +OSVERSION!= /usr/sbin/sysctl -n kern.osreldate
> > > +.endif
> > > +.endif
> > > +
> > > +.if ${OSVERSION} < 400021 || \
> > > +${OSVERSION} >= 50 && ${OSVERSION} < 57
> > > +.PATH: ${.CURDIR}/../../lib/libc/gen
> > > +SRCS+= strtofflags.c
> > > +.endif
> > >
> > > .include
> >
> > Ugh. This is even worse than using __FreeBSD_version. It is broken
> > for non-FreeBSD hosts. Hmm, this case is broken in my version too.
> > Non-FreeBSD hosts might not have have FreeBSD file flags, so they might
> > not have the definitions of the magic numbers necessary for strtofflags.c
> > to compile; they might not even have the necessary headers.
> >
> What do I hear?! Are we required to support non-FreeBSD hosts at the
> Makefile level? That would be too conservative, and is already broken
> in many other ways.
>
> > It is unreasonable to expect the target source strtofflags.c to be
> > compilable in the host environment.
> >
> But we can at least try (with high probability of success) -- this is
> better than the current breakage Jordan observes.
I think it's easier to make a fairly general case work than fix special
cases as they turn up.
> > The correct fix is to not support file flags in the bootstrap
> > version of install.
> >
> But we now always bootstrap install(1). Not including support for
> file flags here would mean "no support for file flags during the
> installworld".
That's certainly a problem. I still don't see the point of the runtime
test to avoid using strtofflags.c. strttofflags.c is just as portable as
the xinstall sources (modulo the dependency on declaring the
things in it, if WARNS is turned on).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
On Wed, Sep 05, 2001 at 09:44:05PM +1000, Bruce Evans wrote:
[...]
> > Index: Makefile
> > ===
> > RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> > retrieving revision 1.15
> > diff -u -r1.15 Makefile
> > --- Makefile2001/04/02 11:54:59 1.15
> > +++ Makefile2001/09/04 08:11:52
> > @@ -3,6 +3,22 @@
> >
> > PROG= xinstall
> > PROGNAME= install
> > +SRCS= xinstall.c
> > MAN= install.1
> > +
> > +# Get __FreeBSD_version
> > +.if !defined(OSVERSION)
> > +.if exists(/sbin/sysctl)
> > +OSVERSION!=/sbin/sysctl -n kern.osreldate
> > +.else
> > +OSVERSION!=/usr/sbin/sysctl -n kern.osreldate
> > +.endif
> > +.endif
> > +
> > +.if ${OSVERSION} < 400021 || \
> > +${OSVERSION} >= 50 && ${OSVERSION} < 57
> > +.PATH: ${.CURDIR}/../../lib/libc/gen
> > +SRCS+= strtofflags.c
> > +.endif
> >
> > .include
>
> Ugh. This is even worse than using __FreeBSD_version. It is broken
> for non-FreeBSD hosts. Hmm, this case is broken in my version too.
> Non-FreeBSD hosts might not have have FreeBSD file flags, so they might
> not have the definitions of the magic numbers necessary for strtofflags.c
> to compile; they might not even have the necessary headers.
>
What do I hear?! Are we required to support non-FreeBSD hosts at the
Makefile level? That would be too conservative, and is already broken
in many other ways.
> It is unreasonable to expect the target source strtofflags.c to be
> compilable in the host environment.
>
But we can at least try (with high probability of success) -- this is
better than the current breakage Jordan observes.
> The correct fix is to not support file flags in the bootstrap
> version of install.
>
But we now always bootstrap install(1). Not including support for
file flags here would mean "no support for file flags during the
installworld".
> > I also think that the ${OSVERSION} stuff should be in sys.mk.
> >
> > > Unfixed bugs: this will have to be fixed better before turning on WARNS.
> > > strtofflags() won't be declared in the host includes if the host libraries
> > > don't have it. Similarly in mtree (where I obtained this fix from) and
> > > in any other tools that use strtofflags(). All these bugs were missing in
> > > the old versions that used ls's version of strtofflags.
> > >
> > This could be solved similarly from within xinstall.c. I.e., we could
> > prototype strtofflags() and fflagstostr() manually if __FreeBSD_version
> > checks fail.
>
> Better to leave it out.
>
OK.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
On Tue, 4 Sep 2001, Ruslan Ermilov wrote:
> On Mon, Sep 03, 2001 at 09:36:46PM +1000, Bruce Evans wrote:
> > Index: Makefile
> > ===
> > RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> > retrieving revision 1.15
> > diff -u -2 -r1.15 Makefile
> > --- Makefile2 Apr 2001 11:54:59 - 1.15
> > +++ Makefile3 Sep 2001 11:18:33 -
> > @@ -2,6 +2,9 @@
> > # $FreeBSD: src/usr.bin/xinstall/Makefile,v 1.15 2001/04/02 11:54:59 ru Exp $
> >
> > +.PATH: ${.CURDIR}/../../lib/libc/gen
> > +
> > PROG= xinstall
> > PROGNAME= install
> > +SRCS= strtofflags.c xinstall.c
> > MAN= install.1
> >
> I don't like this, as it unconditionally compiles in strtofflags.c, even if
> the host has libc support for it. This also breaks single-module-checkout
> compilation. How about this instead?
It shouldn't matter if libc already has strtofflags(). strtofflags is not
in the POSIX namespace and our libc and headers don't have any pollution
;-);-). (Actually, strtofflags is in the (reserved) ISO namespace and thus
in the (reserved) POSIX namespace, especially since xinstall.c includes
and it's already a bug that strtofflags in in .)
Single-module checkout is already broken in hundreds of other places, so
I don't much mind one more (it's broken almost everywhere that uses .PATH,
in particular in all Makefiles for contrib'ed programs).
> The strtofflags() interface has been added
> to HEAD in unistd.h,v 1.36, on 2000/06/17, and
> to RELENG_4 in unistd.h,v 1.35.2.1, on 2000/07/03.
>
> This change has not been reflected by the __FreeBSD_version bump.
No problem. That mistake is not used much outside of /sys :-).
(We've still got ifdefs to support RELENG_2_2 using it :-().
> The nearest (by date) version bumps are as follows:
>
> CURRENT, param.h,v 1.72, 57
> RELENG_4, param.h,v 1.61.2.6: 400021
>
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> retrieving revision 1.15
> diff -u -r1.15 Makefile
> --- Makefile 2001/04/02 11:54:59 1.15
> +++ Makefile 2001/09/04 08:11:52
> @@ -3,6 +3,22 @@
>
> PROG=xinstall
> PROGNAME=install
> +SRCS=xinstall.c
> MAN= install.1
> +
> +# Get __FreeBSD_version
> +.if !defined(OSVERSION)
> +.if exists(/sbin/sysctl)
> +OSVERSION!= /sbin/sysctl -n kern.osreldate
> +.else
> +OSVERSION!= /usr/sbin/sysctl -n kern.osreldate
> +.endif
> +.endif
> +
> +.if ${OSVERSION} < 400021 || \
> +${OSVERSION} >= 50 && ${OSVERSION} < 57
> +.PATH: ${.CURDIR}/../../lib/libc/gen
> +SRCS+= strtofflags.c
> +.endif
>
> .include
Ugh. This is even worse than using __FreeBSD_version. It is broken
for non-FreeBSD hosts. Hmm, this case is broken in my version too.
Non-FreeBSD hosts might not have have FreeBSD file flags, so they might
not have the definitions of the magic numbers necessary for strtofflags.c
to compile; they might not even have the necessary headers. It is
unreasonable to expect the target source strtofflags.c to be compilable
in the host environment. The correct fix is to not support file flags in
the bootstrap version of install.
> I also think that the ${OSVERSION} stuff should be in sys.mk.
>
> > Unfixed bugs: this will have to be fixed better before turning on WARNS.
> > strtofflags() won't be declared in the host includes if the host libraries
> > don't have it. Similarly in mtree (where I obtained this fix from) and
> > in any other tools that use strtofflags(). All these bugs were missing in
> > the old versions that used ls's version of strtofflags.
> >
> This could be solved similarly from within xinstall.c. I.e., we could
> prototype strtofflags() and fflagstostr() manually if __FreeBSD_version
> checks fail.
Better to leave it out.
> > Nearby bugs: mtree/Makefile uses !defined(WORLD) to avoid depending on
> > the host having libmd, but someone removed the definition of WORLD from
> > src/Makefile.inc1.
> >
> The correct fix would be:
>
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/usr.sbin/mtree/Makefile,v
> retrieving revision 1.21
> diff -u -r1.21 Makefile
> --- Makefile 2001/07/20 06:20:02 1.21
> +++ Makefile 2001/09/04 08:22:19
> @@ -8,10 +8,10 @@
> SRCS=compare.c crc.c create.c excludes.c misc.c mtree.c spec.c verify.c \
> strtofflags.c
>
> -.if !defined(WORLD)
> +.include
> +
> +.if defined(LIBMD) && exists(${LIBMD})
> CFLAGS+= -DMD5 -DSHA1 -DRMD160
> DPADD= ${LIBMD}
> LDADD= -lmd
> .endif
> -
> -.include
No, this only detects the presence of libmd, not of the necessary
functions. Something like autoconfig would be needed to detect the
presence and non-brokenness of the necessary functions, but it shouldn't
be necessary to go there.
Bruce
To Unsubscribe: send
Re: Build problem in -current
On Mon, Sep 03, 2001 at 09:36:46PM +1000, Bruce Evans wrote:
> On Sun, 2 Sep 2001, Jordan Hubbard wrote:
>
> > cd /usr/src/usr.bin/xinstall; make _EXTRADEPEND
> > echo xinstall: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
> > cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/xinstall
> > /xinstall.c
> > cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -static -o xinstall xinstal
> > l.o
> > xinstall.o: In function `main':
> > xinstall.o(.text+0x83): undefined reference to `strtofflags'
> > *** Error code 1
> >
> > This is from a relatively old -current coming up to a new (today's)
> > -current. I suspect somebody added a call for install yet forgot to
> > alter the bootstrap tools target accordingly (or did but in the wrong
> > place). Thanks.
>
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> retrieving revision 1.15
> diff -u -2 -r1.15 Makefile
> --- Makefile 2 Apr 2001 11:54:59 - 1.15
> +++ Makefile 3 Sep 2001 11:18:33 -
> @@ -2,6 +2,9 @@
> # $FreeBSD: src/usr.bin/xinstall/Makefile,v 1.15 2001/04/02 11:54:59 ru Exp $
>
> +.PATH: ${.CURDIR}/../../lib/libc/gen
> +
> PROG=xinstall
> PROGNAME=install
> +SRCS=strtofflags.c xinstall.c
> MAN= install.1
>
I don't like this, as it unconditionally compiles in strtofflags.c, even if
the host has libc support for it. This also breaks single-module-checkout
compilation. How about this instead?
The strtofflags() interface has been added
to HEAD in unistd.h,v 1.36, on 2000/06/17, and
to RELENG_4 in unistd.h,v 1.35.2.1, on 2000/07/03.
This change has not been reflected by the __FreeBSD_version bump.
The nearest (by date) version bumps are as follows:
CURRENT, param.h,v 1.72, 57
RELENG_4, param.h,v 1.61.2.6: 400021
Index: Makefile
===
RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile2001/04/02 11:54:59 1.15
+++ Makefile2001/09/04 08:11:52
@@ -3,6 +3,22 @@
PROG= xinstall
PROGNAME= install
+SRCS= xinstall.c
MAN= install.1
+
+# Get __FreeBSD_version
+.if !defined(OSVERSION)
+.if exists(/sbin/sysctl)
+OSVERSION!=/sbin/sysctl -n kern.osreldate
+.else
+OSVERSION!=/usr/sbin/sysctl -n kern.osreldate
+.endif
+.endif
+
+.if ${OSVERSION} < 400021 || \
+${OSVERSION} >= 50 && ${OSVERSION} < 57
+.PATH: ${.CURDIR}/../../lib/libc/gen
+SRCS+= strtofflags.c
+.endif
.include
I also think that the ${OSVERSION} stuff should be in sys.mk.
> Unfixed bugs: this will have to be fixed better before turning on WARNS.
> strtofflags() won't be declared in the host includes if the host libraries
> don't have it. Similarly in mtree (where I obtained this fix from) and
> in any other tools that use strtofflags(). All these bugs were missing in
> the old versions that used ls's version of strtofflags.
>
This could be solved similarly from within xinstall.c. I.e., we could
prototype strtofflags() and fflagstostr() manually if __FreeBSD_version
checks fail.
> Nearby bugs: mtree/Makefile uses !defined(WORLD) to avoid depending on
> the host having libmd, but someone removed the definition of WORLD from
> src/Makefile.inc1.
>
The correct fix would be:
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/mtree/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- Makefile2001/07/20 06:20:02 1.21
+++ Makefile2001/09/04 08:22:19
@@ -8,10 +8,10 @@
SRCS= compare.c crc.c create.c excludes.c misc.c mtree.c spec.c verify.c \
strtofflags.c
-.if !defined(WORLD)
+.include
+
+.if defined(LIBMD) && exists(${LIBMD})
CFLAGS+= -DMD5 -DSHA1 -DRMD160
DPADD= ${LIBMD}
LDADD= -lmd
.endif
-
-.include
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
If you think that's an acceptable work-around then by all means
commit it. Thanks!
- Jordan
From: Bruce Evans <[EMAIL PROTECTED]>
Subject: Re: Build problem in -current
Date: Mon, 3 Sep 2001 21:36:46 +1000 (EST)
> On Sun, 2 Sep 2001, Jordan Hubbard wrote:
>
> > cd /usr/src/usr.bin/xinstall; make _EXTRADEPEND
> > echo xinstall: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
> > cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/xinstall
> > /xinstall.c
> > cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -static -o xinstall xinstal
> > l.o
> > xinstall.o: In function `main':
> > xinstall.o(.text+0x83): undefined reference to `strtofflags'
> > *** Error code 1
> >
> > This is from a relatively old -current coming up to a new (today's)
> > -current. I suspect somebody added a call for install yet forgot to
> > alter the bootstrap tools target accordingly (or did but in the wrong
> > place). Thanks.
>
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
> retrieving revision 1.15
> diff -u -2 -r1.15 Makefile
> --- Makefile 2 Apr 2001 11:54:59 - 1.15
> +++ Makefile 3 Sep 2001 11:18:33 -
> @@ -2,6 +2,9 @@
> # $FreeBSD: src/usr.bin/xinstall/Makefile,v 1.15 2001/04/02 11:54:59 ru Exp $
>
> +.PATH: ${.CURDIR}/../../lib/libc/gen
> +
> PROG=xinstall
> PROGNAME=install
> +SRCS=strtofflags.c xinstall.c
> MAN= install.1
>
> Unfixed bugs: this will have to be fixed better before turning on WARNS.
> strtofflags() won't be declared in the host includes if the host libraries
> don't have it. Similarly in mtree (where I obtained this fix from) and
> in any other tools that use strtofflags(). All these bugs were missing in
> the old versions that used ls's version of strtofflags.
>
> Nearby bugs: mtree/Makefile uses !defined(WORLD) to avoid depending on
> the host having libmd, but someone removed the definition of WORLD from
> src/Makefile.inc1.
>
> Bruce
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Build problem in -current
On Sun, 2 Sep 2001, Jordan Hubbard wrote:
> cd /usr/src/usr.bin/xinstall; make _EXTRADEPEND
> echo xinstall: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend
> cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/xinstall
> /xinstall.c
> cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -static -o xinstall xinstal
> l.o
> xinstall.o: In function `main':
> xinstall.o(.text+0x83): undefined reference to `strtofflags'
> *** Error code 1
>
> This is from a relatively old -current coming up to a new (today's)
> -current. I suspect somebody added a call for install yet forgot to
> alter the bootstrap tools target accordingly (or did but in the wrong
> place). Thanks.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.bin/xinstall/Makefile,v
retrieving revision 1.15
diff -u -2 -r1.15 Makefile
--- Makefile2 Apr 2001 11:54:59 - 1.15
+++ Makefile3 Sep 2001 11:18:33 -
@@ -2,6 +2,9 @@
# $FreeBSD: src/usr.bin/xinstall/Makefile,v 1.15 2001/04/02 11:54:59 ru Exp $
+.PATH: ${.CURDIR}/../../lib/libc/gen
+
PROG= xinstall
PROGNAME= install
+SRCS= strtofflags.c xinstall.c
MAN= install.1
Unfixed bugs: this will have to be fixed better before turning on WARNS.
strtofflags() won't be declared in the host includes if the host libraries
don't have it. Similarly in mtree (where I obtained this fix from) and
in any other tools that use strtofflags(). All these bugs were missing in
the old versions that used ls's version of strtofflags.
Nearby bugs: mtree/Makefile uses !defined(WORLD) to avoid depending on
the host having libmd, but someone removed the definition of WORLD from
src/Makefile.inc1.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Build problem in -current
cd /usr/src/usr.bin/xinstall; make _EXTRADEPEND echo xinstall: /usr/obj/usr/src/i386/usr/lib/libc.a >> .depend cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/xinstall /xinstall.c cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -static -o xinstall xinstal l.o xinstall.o: In function `main': xinstall.o(.text+0x83): undefined reference to `strtofflags' *** Error code 1 This is from a relatively old -current coming up to a new (today's) -current. I suspect somebody added a call for install yet forgot to alter the bootstrap tools target accordingly (or did but in the wrong place). Thanks. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
hum,hum...another build problem...
Hi everyone, this time it is the kernel. i know acpica is in heavy dev. but here's my problem : make buildkernel KERNCONF=NEPTUNE: -- cc -nostdinc -O -pipe -march=pentiumpro -march=pentiumpro -I/usr/obj/usr/build/src/i386/usr/include -c /usr/build/src/sys/i386/acpica/acpi_wakecode.S /usr/build/src/sys/i386/acpica/acpi_wakecode.S:32: machine/specialreg.h: No such file or directory *** Error code 1 Stop in /usr/build/obj/usr/build/src/sys/NEPTUNE. *** Error code 1 Stop in /usr/build/obj/usr/build/src/sys/NEPTUNE. *** Error code 1 Stop in /usr/build/obj/usr/build/src/sys/NEPTUNE. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. -- if you want, you have all files (KERNEL, makekernel.out, dmesg.out) at http://www.deep-ocean.net/~olive/files/. needless to say that my last cvsup is 10 minutes ago. thanks for your advices. as a side note, i resolved the problem of my disks (IBM-DTLA) falling back to PIO4 and hanging the kernel when tagging enabled in /boot/loader.conf : i used to have all my disks in racks. i just put them directly in the box, and all my problem flew away. my builds are much faster : now i can crash many times a day ;-)) regards, Olivier PS: don't pay attention to my strange humor if you don't like it. Sometimes I can't even understand it ;-p To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: build problem ?
On Wed, Jul 25, 2001 at 02:08:07AM +0200, Assar Westerlund wrote: > Olivier Cortes <[EMAIL PROTECTED]> writes: > > fool, fool, fool am i. here it is : > > > > -- > > mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i >386/usr/include > > Make sure you have usr.bin/doscmd/Makefile version 1.28 (or higher). cvsup should have taken care that, shouldn't it ? anyway, i will wait a bit then cvsup again, then build again. i hope i can become more helpful to this list soon :) olivier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: build problem ?
"Scot W. Hetzel" wrote: > When you have a build failure using -j x (x > 1), you need to restart the > build without -j in order to get any meaningful info from the build failure. Unless the breakage is a dependency breakage, not a build breakage, in which case omitting the "-j x" will run to completion without errors, telling you squat. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: build problem ?
Olivier Cortes <[EMAIL PROTECTED]> writes: > fool, fool, fool am i. here it is : > > -- > mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i >386/usr/include Make sure you have usr.bin/doscmd/Makefile version 1.28 (or higher). /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: build problem ?
On Tue, Jul 24, 2001 at 01:47:07PM -0500, Scot W. Hetzel wrote: > When you have a build failure using -j x (x > 1), you need to restart the > build without -j in order to get any meaningful info from the build failure. fool, fool, fool am i. here it is : -- mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i 386/usr/include /usr/build/src/usr.bin/doscmd/AsyncIO.c /usr/build/src/usr.bin/ doscmd/ParseBuffer.c /usr/build/src/usr.bin/doscmd/bios.c /usr/build/src/usr.bin /doscmd/callback.c /usr/build/src/usr.bin/doscmd/cpu.c /usr/build/src/usr.bin/do scmd/dos.c /usr/build/src/usr.bin/doscmd/cmos.c /usr/build/src/usr.bin/doscmd/co nfig.c /usr/build/src/usr.bin/doscmd/cwd.c /usr/build/src/usr.bin/doscmd/debug.c /usr/build/src/usr.bin/doscmd/disktab.c /usr/build/src/usr.bin/doscmd/doscmd.c /usr/build/src/usr.bin/doscmd/ems.c /usr/build/src/usr.bin/doscmd/emuint.c /usr/ build/src/usr.bin/doscmd/exe.c /usr/build/src/usr.bin/doscmd/i386-pinsn.c /usr/b uild/src/usr.bin/doscmd/int.c /usr/build/src/usr.bin/doscmd/int10.c /usr/build/s rc/usr.bin/doscmd/int13.c /usr/build/src/usr.bin/doscmd/int14.c /usr/build/src/u sr.bin/doscmd/int16.c /usr/build/src/usr.bin/doscmd/int17.c /usr/build/src/usr.b in/doscmd/int1a.c /usr/build/src/usr.bin/doscmd/int2f.c /usr/build/src/usr.bin/d oscmd/intff.c /usr/build/src/usr.bin/doscmd/mem.c /usr/build/src/usr.bin/doscmd/ mouse.c /usr/build/src/usr.bin/doscmd/net.c /usr/build/src/usr.bin/doscmd/port.c /usr/build/src/usr.bin/doscmd/setver.c /usr/build/src/usr.bin/doscmd/signal.c / usr/build/src/usr.bin/doscmd/timer.c /usr/build/src/usr.bin/doscmd/trace.c /usr/ build/src/usr.bin/doscmd/trap.c /usr/build/src/usr.bin/doscmd/tty.c /usr/build/s rc/usr.bin/doscmd/video.c /usr/build/src/usr.bin/doscmd/xms.c /usr/build/src/usr.bin/doscmd/tty.c:66: font8x8.h: No such file or directory /usr/build/src/usr.bin/doscmd/tty.c:67: font8x14.h: No such file or directory /usr/build/src/usr.bin/doscmd/tty.c:68: font8x16.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/build/src/usr.bin/doscmd. *** Error code 1 Stop in /usr/build/src/usr.bin. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. - yesterday, the kernel didn't compile, but world did. today it's the contrary... thanks for the advice. sure i must have done it BEFORE sending the mail. sorry. Olivier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: build problem ?
From: "Olivier Cortes" <[EMAIL PROTECTED]> > i cvsuped 20 minutes ago. > > when i try to build (-j 6), it says: > > > i couln't find the exact error point... i have a full make.out (make > -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if > you want to look at it. > > i know broken builds are frequent under -CURRENT, but i couldn't > figure the source of this one. advises are welcome. > When you have a build failure using -j x (x > 1), you need to restart the build without -j in order to get any meaningful info from the build failure. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
build problem ?
hi ! i cvsuped 20 minutes ago. when i try to build (-j 6), it says: -- lex -t -I /usr/build/src/usr.sbin/pcvt/kbdio/lex.l > lex.c yacc: 2 shift/reduce conflicts cp y.tab.c kbdio.c rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/build/obj/usr/build/src/usr.sbin/pcvt/kbdio -I/usr/build/src/usr.sbin/pcvt/kbdio -I/usr/obj/usr/build/src/i386/usr /include kbdio.c lex.c cd /usr/build/src/usr.sbin/pcvt/kbdio; make _EXTRADEPEND echo kbdio: /usr/obj/usr/build/src/i386/usr/lib/libc.a /usr/obj/usr/build/src/i386/usr/lib/libm.a /usr/obj/usr/build/src/i386/usr/lib/liby.a /usr/obj/usr /build/src/i386/usr/lib/libl.a >> .depend ===> usr.sbin/pcvt/demo rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/pcvt/demo/playvt.c cd /usr/build/src/usr.sbin/pcvt/demo; make _EXTRADEPEND echo playvt: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/pcvt/Misc ===> usr.sbin/pcvt/Misc/Doc ===> usr.sbin/pcvt/Misc/Etc ===> usr.sbin/sgsc rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/sgsc/sgsc.c cd /usr/build/src/usr.sbin/sgsc; make _EXTRADEPEND echo sgsc: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/sicontrol rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/build/src/usr.sbin/sicontrol/../../sys -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/sicontro l/sicontrol.c cd /usr/build/src/usr.sbin/sicontrol; make _EXTRADEPEND echo sicontrol: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/spkrtest ===> usr.sbin/stallion ===> usr.sbin/stallion/bootcode ===> usr.sbin/stallion/stlload rm -f .depend mkdep -f .depend -a -nostdinc -DBOOTDIR=\"/usr/libdata/stallion\" -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/stallion/stlload/s tlload.c cd /usr/build/src/usr.sbin/stallion/stlload; make _EXTRADEPEND echo stlload: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/stallion/stlstats rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/stallion/stlstats/stlstats.c cd /usr/build/src/usr.sbin/stallion/stlstats; make _EXTRADEPEND echo stlstats: /usr/obj/usr/build/src/i386/usr/lib/libc.a /usr/obj/usr/build/src/i386/usr/lib/libncurses.a >> .depend ===> usr.sbin/wlconfig rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/wlconfig/wlconfig.c cd /usr/build/src/usr.sbin/wlconfig; make _EXTRADEPEND echo wlconfig: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/boot0cfg rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/boot0cfg/boot0cfg.c cd /usr/build/src/usr.sbin/boot0cfg; make _EXTRADEPEND echo boot0cfg: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend 1 error *** Error code 2 1 error *** Error code 2 1 error -- i couln't find the exact error point... i have a full make.out (make -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if you want to look at it. i know broken builds are frequent under -CURRENT, but i couldn't figure the source of this one. advises are welcome. (at http://www.deep-ocean.net/~olive/files/, i'll put a dmesg.out, my kernel file (renamed kernel.out ; otherwise it is NEPTUNE). It's always good to have them near.) and sorry for my approximate english, it's not my native language. regards, --- Olivier Cortes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent -CURRENT kernel build problem...
John Indra <[EMAIL PROTECTED]> writes: > Yeah... finally, my world is in sync with the kernel, what a joy :) > Until know... the system is pretty stable. > Will this be committed to the tree soon? It has been comitted, I just wanted to test building first. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent -CURRENT kernel build problem...
On Tue, Dec 19, 2000 at 09:22:57AM +0100, [EMAIL PROTECTED] wrote: >Can you try the appended patch and tell us how it goes? Yeah... finally, my world is in sync with the kernel, what a joy :) Until know... the system is pretty stable. Will this be committed to the tree soon? Thank you very much... Regards, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent -CURRENT kernel build problem...
On Tue, Dec 19, 2000 at 10:16:01AM +0200, Ruslan Ermilov wrote: >If I remeber correctly, someone else reported this was caused by >phk's change staticizing something... Sorry, I do not recall this >in details, and I don't have a fresh -CURRENT. OK then... Any workaround or fix coming shortly to overcome this guys? BTW... I am very interested to become one of you guys, the FreeBSD committers. I mean it. I am ready to devote my life to FreeBSD (if this phrase is not too much :) ). Now I am still trying to finish my Bachelor degree. In the mean time I am working as a Network Administrator for a company in Indonesia. Soon after I finish my school, I will have plenty of time to study C and maybe try to understand piece by piece FreeBSD codes, maybe not in all section, and if I am qualified enough, I'd like to contribute something to FreeBSD. What I need now is a guidance. I think I'm not a very novice programmer. For my bachelor degree, I'm trying to make a Natural Language enabled (at semantic level) search engine. Planning to use Perl to build the beast :) Where can I start to dig more information about OS, efficient programming with C, etc. to help me get what I want? Sorry, I think this is becoming out of topic, but I'm very glad to have said my wish :) Thanks a lot... Regards, John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent -CURRENT kernel build problem...
John Indra <[EMAIL PROTECTED]> writes: > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev > -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL > -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c > linking kernel > agp_amd.o: In function `agp_amd_alloc_gatt': > agp_amd.o(.text+0x67): undefined reference to `M_AGP' > agp_amd.o(.text+0x89): undefined reference to `M_AGP' > agp_amd.o(.text+0xd5): undefined reference to `M_AGP' > agp_amd.o(.text+0x105): undefined reference to `M_AGP' > agp_amd.o(.text+0x112): undefined reference to `M_AGP' > agp_amd.o(.text+0x234): more undefined references to `M_AGP' follow > *** Error code 1 Can you try the appended patch and tell us how it goes? /assar Index: agp.c === RCS file: /home/ncvs/src/sys/pci/agp.c,v retrieving revision 1.9 diff -u -w -u -w -r1.9 agp.c --- agp.c 2000/12/12 20:24:36 1.9 +++ agp.c 2000/12/19 08:22:01 @@ -59,7 +59,7 @@ MODULE_VERSION(agp, 1); -static MALLOC_DEFINE(M_AGP, "agp", "AGP data structures"); +MALLOC_DEFINE(M_AGP, "agp", "AGP data structures"); #define CDEV_MAJOR 148 /* agp_drv.c */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent -CURRENT kernel build problem...
If I remeber correctly, someone else reported this was caused by phk's change staticizing something... Sorry, I do not recall this in details, and I don't have a fresh -CURRENT. On Tue, Dec 19, 2000 at 02:35:54PM +0700, John Indra wrote: > Dear all... > > Has anyone noticed this problem? Or is it just happening to me? > On make buildkernel (with -CURRENT just cvsuped a few minutes ago) and the > generic config KERNEL; make depend; make; cycle, the kernel build failed > with this message: > > -- > > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev > -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL > -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c > linking kernel > agp_amd.o: In function `agp_amd_alloc_gatt': > agp_amd.o(.text+0x67): undefined reference to `M_AGP' > agp_amd.o(.text+0x89): undefined reference to `M_AGP' > agp_amd.o(.text+0xd5): undefined reference to `M_AGP' > agp_amd.o(.text+0x105): undefined reference to `M_AGP' > agp_amd.o(.text+0x112): undefined reference to `M_AGP' > agp_amd.o(.text+0x234): more undefined references to `M_AGP' follow > *** Error code 1 > > Stop in /usr/src/sys/compile/DANTE. > > -- > > Please help, my kernel and userland is badly not in sync ;) > Attached is my kernel config file. > > Thank you... > > Regards, > John > > ident DANTE > machine i386 > cpu I686_CPU > maxusers 256 > > options INET > options FFS > options FFS_ROOT > options SOFTUPDATES > options COMPAT_43 > options UCONSOLE > options USERCONFIG > options VISUAL_USERCONFIG > options KTRACE > options SYSVSHM > options SYSVMSG > options SYSVSEM > options SHMMAX=33554432 > options SHMALL=16384 > options P1003_1B > options _KPOSIX_PRIORITY_SCHEDULING > options KBD_INSTALL_CDEV > options ATA_STATIC_ID > options ATA_ENABLE_ATAPI_DMA > options USER_LDT > options IPFILTER > options IPFILTER_LOG > options TCP_DROP_SYNFIN > options TCP_RESTRICT_RST > options VESA > options NMBCLUSTERS=16384 > options SC_DISABLE_REBOOT > options NOBLOCKRANDOM > > deviceisa > devicepci > devicefdc > deviceata > deviceatadisk > deviceatapicd > deviceatkbdc 1 > deviceatkbd > devicepsm > devicevga > devicesplash > devicesc 1 > devicenpx > deviceapm > devicesio > deviceppc > deviceppbus > devicelpt > deviceplip > deviceppi > devicemiibus > devicexl > devicerandom > deviceloop > deviceether > devicetun > devicepty > devicemd > devicebpf > devicevn > devicesnp > devicepcm > deviceagp -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent -CURRENT kernel build problem...
Dear all... Has anyone noticed this problem? Or is it just happening to me? On make buildkernel (with -CURRENT just cvsuped a few minutes ago) and the generic config KERNEL; make depend; make; cycle, the kernel build failed with this message: -- cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c linking kernel agp_amd.o: In function `agp_amd_alloc_gatt': agp_amd.o(.text+0x67): undefined reference to `M_AGP' agp_amd.o(.text+0x89): undefined reference to `M_AGP' agp_amd.o(.text+0xd5): undefined reference to `M_AGP' agp_amd.o(.text+0x105): undefined reference to `M_AGP' agp_amd.o(.text+0x112): undefined reference to `M_AGP' agp_amd.o(.text+0x234): more undefined references to `M_AGP' follow *** Error code 1 Stop in /usr/src/sys/compile/DANTE. -- Please help, my kernel and userland is badly not in sync ;) Attached is my kernel config file. Thank you... Regards, John ident DANTE machine i386 cpu I686_CPU maxusers256 options INET options FFS options FFS_ROOT options SOFTUPDATES options COMPAT_43 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options SHMMAX=33554432 options SHMALL=16384 options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options ATA_STATIC_ID options ATA_ENABLE_ATAPI_DMA options USER_LDT options IPFILTER options IPFILTER_LOG options TCP_DROP_SYNFIN options TCP_RESTRICT_RST options VESA options NMBCLUSTERS=16384 options SC_DISABLE_REBOOT options NOBLOCKRANDOM device isa device pci device fdc device ata device atadisk device atapicd device atkbdc 1 device atkbd device psm device vga device splash device sc 1 device npx device apm device sio device ppc device ppbus device lpt device plip device ppi device miibus device xl device random device loop device ether device tun device pty device md device bpf device vn device snp device pcm device agp
Re: kernel build problem
On Fri, Oct 27, 2000 at 10:46:24PM +1100, Darren Reed wrote: > I'm generally compiling/developing on -STABLE (in this case, the > imported code was compiling cleanly on 4.1-RELEASE) and generally don't > think that it'll be _that_ different. In all seriousness, the farther down the 4.x branch we get, the divergence between -STABLE and -CURRENT gets *quite* different. This is unfortunate, but until we do major paid release engineering, many things are MFC'ed that really could/should be to reduce the differences. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build problem
In some email I received from David O'Brien, sie wrote: > On Fri, Oct 27, 2000 at 11:43:04AM +0200, Poul-Henning Kamp wrote: > > In message <[EMAIL PROTECTED]>, Darren Reed writes > > : > > >What failed ? Do you have the make error output ? > > Did you try to compile LINT before you committed ? > > Hell, forget LINT, just try GENERIC. > > Darren, you really, really have a major problem importing new ipfilter > bits. I cannot think of a single time you have not broken world. What > can we do to help you prevent this in the future? Do you compile a > GENERIC and/or LINT kernel before your change(s)? Do you ``cvsup'' and > then test what actually got committed in a virgin src tree? I don't use cvsup (but may soon) as I have to pay for megabytes at the moment. I'm generally compiling/developing on -STABLE (in this case, the imported code was compiling cleanly on 4.1-RELEASE) and generally don't think that it'll be _that_ different. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build problem
On Fri, Oct 27, 2000 at 11:43:04AM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Darren Reed writes > : > >What failed ? Do you have the make error output ? > Did you try to compile LINT before you committed ? Hell, forget LINT, just try GENERIC. Darren, you really, really have a major problem importing new ipfilter bits. I cannot think of a single time you have not broken world. What can we do to help you prevent this in the future? Do you compile a GENERIC and/or LINT kernel before your change(s)? Do you ``cvsup'' and then test what actually got committed in a virgin src tree? -- -- David ([EMAIL PROTECTED]) P.S. ===> ipfilter rm -f .depend mkdep -f .depend -a -nostdinc -DIPFILTER=1 -DIPFILTER_LKM -DIPFILTER_LOG -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include /usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c /usr/src/sys/modules/ipfilter/../../netinet/ip_nat.c /usr/src/sys/modules/ipfilter/../../netinet/ip_frag.c /usr/src/sys/modules/ipfilter/../../netinet/ip_state.c /usr/src/sys/modules/ipfilter/../../netinet/ip_proxy.c /usr/src/sys/modules/ipfilter/../../netinet/ip_auth.c /usr/src/sys/modules/ipfilter/../../netinet/ip_log.c /usr/src/sys/modules/ipfilter/../../netinet/ip_fil.c /usr/src/sys/modules/ipfilter/../../netinet/fil.c In file included from /usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c:44: @/netinet/ip_compat.h:268: osreldate.h: No such file or directory ..snip.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build problem
Darren Reed wrote: > > What failed ? Do you have the make error output ? In file included from /usr/amd/slave/usr/current/src/sys/netinet/fil.c:79: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_auth.c:93: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_fil.c:101: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_frag.c:71: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_log.c:112: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_nat.c:99: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_proxy.c:72: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/ip_state.c:82: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory In file included from /usr/amd/slave/usr/current/src/sys/netinet/mlfk_ipl.c:44: /usr/amd/slave/usr/current/src/sys/netinet/ip_compat.h:271: sys/osreldate.h: No such file or directory HTH, Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build problem
In message <[EMAIL PROTECTED]>, Darren Reed writes : >What failed ? Do you have the make error output ? Did you try to compile LINT before you committed ? Right, if you had you would have seen the error :-( >Darren >> Index: ip_compat.h >> === >> RCS file: /usr/ncvs/src/sys/netinet/ip_compat.h,v >> retrieving revision 1.11 >> diff -u -r1.11 ip_compat.h >> --- ip_compat.h 2000/10/26 12:33:42 1.11 >> +++ ip_compat.h 2000/10/27 06:14:46 >> @@ -265,10 +265,10 @@ >> >> #if defined(__FreeBSD__) && (defined(KERNEL) || defined(_KERNEL)) >> # ifdef IPFILTER_LKM >> -# include >> +# include >> # define ACTUALLY_LKM_NOT_KERNEL >> # else >> -# include >> +# include >> # endif >> # if __FreeBSD__ < 3 >> # include >> >> >> -- >> "The dead cannot be seduced." >> - Kai, "Lexx" >> >> Do YOU Yahoo!? >> >> >> >> > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel build problem
What failed ? Do you have the make error output ? Darren In some email I received from Doug Barton, sie wrote: > With tonight's sources I had an error in sys/netinet/ip_compat.h that > was looking for an osreldate.h that didn't exist. The following patch > fixes it, in the sense that the kernel and lkm compile, and ipfilter > compiled into the kernel works. However I'm told it might not be > appropriate. FWIW, I'm using buildkernel, and I can see > src/i386/usr/include/osreldate.h and src/include/osreldate.h both in > /usr/obj. > > Doug > > Index: ip_compat.h > === > RCS file: /usr/ncvs/src/sys/netinet/ip_compat.h,v > retrieving revision 1.11 > diff -u -r1.11 ip_compat.h > --- ip_compat.h 2000/10/26 12:33:42 1.11 > +++ ip_compat.h 2000/10/27 06:14:46 > @@ -265,10 +265,10 @@ > > #if defined(__FreeBSD__) && (defined(KERNEL) || defined(_KERNEL)) > # ifdef IPFILTER_LKM > -# include > +# include > # define ACTUALLY_LKM_NOT_KERNEL > # else > -# include > +# include > # endif > # if __FreeBSD__ < 3 > # include > > > -- > "The dead cannot be seduced." > - Kai, "Lexx" > > Do YOU Yahoo!? > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel build problem
With tonight's sources I had an error in sys/netinet/ip_compat.h that was looking for an osreldate.h that didn't exist. The following patch fixes it, in the sense that the kernel and lkm compile, and ipfilter compiled into the kernel works. However I'm told it might not be appropriate. FWIW, I'm using buildkernel, and I can see src/i386/usr/include/osreldate.h and src/include/osreldate.h both in /usr/obj. Doug Index: ip_compat.h === RCS file: /usr/ncvs/src/sys/netinet/ip_compat.h,v retrieving revision 1.11 diff -u -r1.11 ip_compat.h --- ip_compat.h 2000/10/26 12:33:42 1.11 +++ ip_compat.h 2000/10/27 06:14:46 @@ -265,10 +265,10 @@ #if defined(__FreeBSD__) && (defined(KERNEL) || defined(_KERNEL)) # ifdef IPFILTER_LKM -# include +# include # define ACTUALLY_LKM_NOT_KERNEL # else -# include +# include # endif # if __FreeBSD__ < 3 # include -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl6 first time build problem
On Sat, Jul 01, 2000 at 12:55:25PM +0200, Mark Murray wrote: > Do a "make build-tools" first. I'm working on getting this done properly > into cross-tools. I found more quick manual way: 1) building/installing libperl 2) building/installing miniperl 3) to do the rest BTW, is there a way to add CFLAGS (highly-optimized for me) when building additional perl object modules? I see something with name 'cflags' extracted now, so it can helps maybe. This problem stays too long... -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl6 first time build problem
> I say "make cleandir; make obj; make depend;" in perl directory and got: Hi Do a "make build-tools" first. I'm working on getting this done properly into cross-tools. A real "make world" will also bootstrap you properly. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
perl6 first time build problem
I say "make cleandir; make obj; make depend;" in perl directory and got: ... ===> perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) /usr/obj/usr/src/gnu/usr.bin/perl/perl/../miniperl/miniperl:No such file or dire ctory *** Error code 1 -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
