Re: Python numpy Floating point exception in latest snapshot
I'm really sorry, my files were broken. I didn't have any unexpected power outage, so I never expected that my files might be broken. I fixed my files using this command: # pkg_add -uDsnap -Dinstalled -Dchecksum Ali Farzanrad wrote: > Hi Stuart, > > Stuart Henderson wrote: > > I don't see that here. > > > > Firstly, did you run pkg_add -u after updating? > > Yes. I also ran this command to ensure everything is up to date: > # pkg_add -uDsnap -Dinstalled > > However I couldn't reproduce this error on a clean install on same > computer (Minisforum UM790 with Ryzen 9 7940HS). > > > Install the gdb and debug-py3-numpy packages (as well as the > > debug-python you already have) and use the 'egdb' binary. The version > > of gdb in base is barely useful. > > It seems that lldb is working, so I included my lldb output at the end > of this email. > > > Which cpu architecture? amd64, arm64, sparc64, [...]? > > amd64 > > > $ lldb /usr/local/bin/python3.11 > (lldb) target create "/usr/local/bin/python3.11" > Current executable set to '/usr/local/bin/python3.11' (x86_64). > (lldb) run -c "import numpy" > Process 48416 launched: '/usr/local/bin/python3.11' (x86_64) > Process 48416 stopped > * thread #1, stop reason = signal SIGFPE > frame #0: 0x069e436d7ea5 > ld.so`_dl_find_symbol_obj(obj=0x069e12186000, sl=0x784c8e3b7198) at > resolve.c:626:46 >623 } else { >624 Elf_Word si; >625 > -> 626 for (si = obj->buckets_elf[sl->sl_elf_hash % > obj->nbuckets]; >^ >627 si != STN_UNDEF; si = obj->chains_elf[si]) { >628 const Elf_Sym *sym = symt + si; >629 > (lldb) list >630 int r = matched_symbol(obj, sym, sl); >631 if (r) >632 return r > 0; >633 } >634 } >635 return 0; >636 } > (lldb) print obj > (elf_object_t *) $0 = 0x069e12186000 > (lldb) print obj->nbuckets > (u_int32_t) $1 = 0 > (lldb) bt > * thread #1, stop reason = signal SIGFPE > * frame #0: 0x069e436d7ea5 > ld.so`_dl_find_symbol_obj(obj=0x069e12186000, sl=0x784c8e3b7198) at > resolve.c:626:46 > frame #1: 0x069e436d7b80 > ld.so`_dl_find_symbol(name="PyInit__multiarray_umath", flags=96, > ref_sym=0x, req_obj=0x069e12186000) at resolve.c:669:7 > frame #2: 0x069e436d3a82 ld.so`dlsym(handle=, > name="PyInit__multiarray_umath") at dlfcn.c:206:7 > frame #3: 0x069eeb781e9e > libpython3.11.so.0.0`_PyImport_FindSharedFuncptr(prefix="PyInit", > shortname="_multiarray_umath", > pathname="/usr/local/lib/python3.11/site-packages/numpy/core/_multiarray_umath.cpython-311.so", > fp=0x) at dynload_shlib.c:109:22 > frame #4: 0x069eeb73621f libpython3.11.so.0.0`_imp_create_dynamic at > importdl.c:139:18 > frame #5: 0x069eeb63da1e > libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL at methodobject.c:427:24 > frame #6: 0x069eeb6fcaec > libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 > frame #7: 0x069eeb6ff24b libpython3.11.so.0.0`_PyEval_Vector at > pycore_ceval.h:73:16 > frame #8: 0x069eeb5e3261 libpython3.11.so.0.0`object_vacall at > pycore_call.h:92:11 > frame #9: 0x069eeb5e3043 > libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 > frame #10: 0x069eeb730fec > libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1748:11 > frame #11: 0x069eeb6f5236 > libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:7422:15 > frame #12: 0x069eeb6e985e libpython3.11.so.0.0`PyEval_EvalCode at > pycore_ceval.h:73:16 > frame #13: 0x069eeb6e4e9f libpython3.11.so.0.0`builtin_exec at > bltinmodule.c:1077:17 > frame #14: 0x069eeb63db39 > libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL_KEYWORDS at > methodobject.c:443:24 > frame #15: 0x069eeb6fcaec > libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 > frame #16: 0x069eeb6ff24b libpython3.11.so.0.0`_PyEval_Vector at > pycore_ceval.h:73:16 > frame #17: 0x069eeb5e3261 libpython3.11.so.0.0`object_vacall at > pycore_call.h:92:11 > frame #18: 0x069eeb5e3043 > libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 > frame #19: 0x069eeb730fec > libpython3.11.so.0.0`PyImport_ImportModuleLevelOb
Re: Python numpy Floating point exception in latest snapshot
Hi Stuart, Stuart Henderson wrote: > I don't see that here. > > Firstly, did you run pkg_add -u after updating? Yes. I also ran this command to ensure everything is up to date: # pkg_add -uDsnap -Dinstalled However I couldn't reproduce this error on a clean install on same computer (Minisforum UM790 with Ryzen 9 7940HS). > Install the gdb and debug-py3-numpy packages (as well as the > debug-python you already have) and use the 'egdb' binary. The version > of gdb in base is barely useful. It seems that lldb is working, so I included my lldb output at the end of this email. > Which cpu architecture? amd64, arm64, sparc64, [...]? amd64 $ lldb /usr/local/bin/python3.11 (lldb) target create "/usr/local/bin/python3.11" Current executable set to '/usr/local/bin/python3.11' (x86_64). (lldb) run -c "import numpy" Process 48416 launched: '/usr/local/bin/python3.11' (x86_64) Process 48416 stopped * thread #1, stop reason = signal SIGFPE frame #0: 0x069e436d7ea5 ld.so`_dl_find_symbol_obj(obj=0x069e12186000, sl=0x784c8e3b7198) at resolve.c:626:46 623 } else { 624 Elf_Word si; 625 -> 626 for (si = obj->buckets_elf[sl->sl_elf_hash % obj->nbuckets]; ^ 627 si != STN_UNDEF; si = obj->chains_elf[si]) { 628 const Elf_Sym *sym = symt + si; 629 (lldb) list 630 int r = matched_symbol(obj, sym, sl); 631 if (r) 632 return r > 0; 633 } 634 } 635 return 0; 636 } (lldb) print obj (elf_object_t *) $0 = 0x069e12186000 (lldb) print obj->nbuckets (u_int32_t) $1 = 0 (lldb) bt * thread #1, stop reason = signal SIGFPE * frame #0: 0x069e436d7ea5 ld.so`_dl_find_symbol_obj(obj=0x069e12186000, sl=0x784c8e3b7198) at resolve.c:626:46 frame #1: 0x069e436d7b80 ld.so`_dl_find_symbol(name="PyInit__multiarray_umath", flags=96, ref_sym=0x, req_obj=0x069e12186000) at resolve.c:669:7 frame #2: 0x069e436d3a82 ld.so`dlsym(handle=, name="PyInit__multiarray_umath") at dlfcn.c:206:7 frame #3: 0x069eeb781e9e libpython3.11.so.0.0`_PyImport_FindSharedFuncptr(prefix="PyInit", shortname="_multiarray_umath", pathname="/usr/local/lib/python3.11/site-packages/numpy/core/_multiarray_umath.cpython-311.so", fp=0x) at dynload_shlib.c:109:22 frame #4: 0x069eeb73621f libpython3.11.so.0.0`_imp_create_dynamic at importdl.c:139:18 frame #5: 0x069eeb63da1e libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL at methodobject.c:427:24 frame #6: 0x069eeb6fcaec libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 frame #7: 0x069eeb6ff24b libpython3.11.so.0.0`_PyEval_Vector at pycore_ceval.h:73:16 frame #8: 0x069eeb5e3261 libpython3.11.so.0.0`object_vacall at pycore_call.h:92:11 frame #9: 0x069eeb5e3043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #10: 0x069eeb730fec libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1748:11 frame #11: 0x069eeb6f5236 libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:7422:15 frame #12: 0x069eeb6e985e libpython3.11.so.0.0`PyEval_EvalCode at pycore_ceval.h:73:16 frame #13: 0x069eeb6e4e9f libpython3.11.so.0.0`builtin_exec at bltinmodule.c:1077:17 frame #14: 0x069eeb63db39 libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL_KEYWORDS at methodobject.c:443:24 frame #15: 0x069eeb6fcaec libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 frame #16: 0x069eeb6ff24b libpython3.11.so.0.0`_PyEval_Vector at pycore_ceval.h:73:16 frame #17: 0x069eeb5e3261 libpython3.11.so.0.0`object_vacall at pycore_call.h:92:11 frame #18: 0x069eeb5e3043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #19: 0x069eeb730fec libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1748:11 frame #20: 0x069eeb6e3609 libpython3.11.so.0.0`builtin___import__ at bltinmodule.c:277:12 frame #21: 0x069eeb63db39 libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL_KEYWORDS at methodobject.c:443:24 frame #22: 0x069eeb6fcaec libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 frame #23: 0x069eeb6ff24b libpython3.11.so.0.0`_PyEval_Vector at pycore_ceval.h:73:16 frame #24: 0x069eeb5e3261 libpython3.11.so.0.0`object_vacall at pycore_call.h:92:11 frame #25: 0x069eeb5e3043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #26: 0x069eeb7311e2 libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1918:25 frame #27: 0x069eeb6f5236 libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:7422:15 frame #28: 0x069eeb6e985e
Re: Python numpy Floating point exception in latest snapshot
2:11 frame #41: 0x03e0bc071043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #42: 0x03e0bc1bf1e2 libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1918:25 frame #43: 0x03e0bc183236 libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:7422:15 frame #44: 0x03e0bc17785e libpython3.11.so.0.0`PyEval_EvalCode at pycore_ceval.h:73:16 frame #45: 0x03e0bc172e9f libpython3.11.so.0.0`builtin_exec at bltinmodule.c:1077:17 frame #46: 0x03e0bc0cbb39 libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL_KEYWORDS at methodobject.c:443:24 frame #47: 0x03e0bc18aaec libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 frame #48: 0x03e0bc18d24b libpython3.11.so.0.0`_PyEval_Vector at pycore_ceval.h:73:16 frame #49: 0x03e0bc071261 libpython3.11.so.0.0`object_vacall at pycore_call.h:92:11 frame #50: 0x03e0bc071043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #51: 0x03e0bc1befec libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1748:11 frame #52: 0x03e0bc171609 libpython3.11.so.0.0`builtin___import__ at bltinmodule.c:277:12 frame #53: 0x03e0bc0cbb39 libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL_KEYWORDS at methodobject.c:443:24 frame #54: 0x03e0bc18aaec libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 frame #55: 0x03e0bc18d24b libpython3.11.so.0.0`_PyEval_Vector at pycore_ceval.h:73:16 frame #56: 0x03e0bc071261 libpython3.11.so.0.0`object_vacall at pycore_call.h:92:11 frame #57: 0x03e0bc071043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #58: 0x03e0bc1bf1e2 libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1918:25 frame #59: 0x03e0bc183236 libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:7422:15 frame #60: 0x03e0bc17785e libpython3.11.so.0.0`PyEval_EvalCode at pycore_ceval.h:73:16 frame #61: 0x03e0bc172e9f libpython3.11.so.0.0`builtin_exec at bltinmodule.c:1077:17 frame #62: 0x03e0bc0cbb39 libpython3.11.so.0.0`cfunction_vectorcall_FASTCALL_KEYWORDS at methodobject.c:443:24 frame #63: 0x03e0bc18aaec libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:0 frame #64: 0x03e0bc18d24b libpython3.11.so.0.0`_PyEval_Vector at pycore_ceval.h:73:16 frame #65: 0x03e0bc071261 libpython3.11.so.0.0`object_vacall at pycore_call.h:92:11 frame #66: 0x03e0bc071043 libpython3.11.so.0.0`PyObject_CallMethodObjArgs at call.c:879:24 frame #67: 0x03e0bc1befec libpython3.11.so.0.0`PyImport_ImportModuleLevelObject at import.c:1748:11 frame #68: 0x03e0bc183236 libpython3.11.so.0.0`_PyEval_EvalFrameDefault at ceval.c:7422:15 frame #69: 0x03e0bc17785e libpython3.11.so.0.0`PyEval_EvalCode at pycore_ceval.h:73:16 frame #70: 0x03e0bc1e8429 libpython3.11.so.0.0`run_mod [inlined] run_eval_code_obj(tstate=0x03e0bc3cb760, co=0x03e0e8f475d0, globals=0x03e0e90182c0, locals=0x03e0e90182c0) at pythonrun.c:1741:9 frame #71: 0x03e0bc1e83f5 libpython3.11.so.0.0`run_mod(mod=, filename=, globals=0x03e0e90182c0, locals=0x03e0e90182c0, flags=, arena=) at pythonrun.c:1762:19 frame #72: 0x03e0bc1ebf30 libpython3.11.so.0.0`PyRun_SimpleStringFlags [inlined] PyRun_StringFlags(str="import numpy\n", start=257, globals=0x03e0e90182c0, locals=0x03e0e90182c0, flags=0x76bd10e851d0) at pythonrun.c:1632:15 frame #73: 0x03e0bc1ebedc libpython3.11.so.0.0`PyRun_SimpleStringFlags(command="import numpy\n", flags=0x76bd10e851d0) at pythonrun.c:487:9 frame #74: 0x03e0bc210722 libpython3.11.so.0.0`Py_RunMain [inlined] pymain_run_command(command=) at main.c:255:11 frame #75: 0x03e0bc210693 libpython3.11.so.0.0`Py_RunMain [inlined] pymain_run_python(exitcode=) at main.c:592:21 frame #76: 0x03e0bc2105b0 libpython3.11.so.0.0`Py_RunMain at main.c:680:5 frame #77: 0x03e0bc211e45 libpython3.11.so.0.0`pymain_main(args=0x76bd10e85578) at main.c:710:12 frame #78: 0x03e0bc21226c libpython3.11.so.0.0`Py_BytesMain(argc=, argv=0x76bd10e81f68) at main.c:734:12 frame #79: 0x03de38a6894b python3.11`__start + 299 Ali Farzanrad wrote: > Hi, > > I see this error in latest snapshot: > > $ python3.11 -c 'import numpy' > Floating point exception (core dumped) > > I installed debug-python package to debug, but I have no idea how to > debug it: > > $ gdb -- /usr/local/bin/python3.11 > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show
Python numpy Floating point exception in latest snapshot
Hi, I see this error in latest snapshot: $ python3.11 -c 'import numpy' Floating point exception (core dumped) I installed debug-python package to debug, but I have no idea how to debug it: $ gdb -- /usr/local/bin/python3.11 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd7.5"... (gdb) run -c 'import numpy' Starting program: /usr/local/bin/python3.11 -c 'import numpy' Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] Error while reading shared library symbols: Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so] warning: no loadable sections found in added symbol-file /usr/local/lib/python3.11/site-packages/numpy/core/_multiarray_umath.cpython-311.so Program received signal SIGFPE, Arithmetic exception. 0x030e5995dc35 in ?? () from /usr/libexec/ld.so (gdb) bt #0 0x030e5995dc35 in ?? () from /usr/libexec/ld.so #1 0x030f0f124b30 in ?? () #2 0x in ?? () (gdb) list 5 python.c: No such file or directory. in python.c
chromium crash on arm64
Hi, I'm using chromium on my Thinkpad X13s laptop which has an aarch64 CPU. Recently I noticed that my chromium will crash when visiting many of popular websites (for example lenovo.com) but after increasing datasize limit, it works: (ulimit -d 2097152 && chromium) So I think it was about datasize limit. Could you mention this on package README?
Re: Non-standard allocations in games/vkquake
Thomas Frohwein wrote: > On Sat, Mar 11, 2023 at 08:24:58AM +0000, Ali Farzanrad wrote: > > Thomas Frohwein wrote: > > > On Fri, Mar 10, 2023 at 08:36:06PM +0000, Ali Farzanrad wrote: > > > [...] > > > > > > Please leave in the hunk that removes -Werror > > > > > > > > > > yes, what's the reason for this being in the diff/ > > > > > > > > I thought that you've removed that -Werror mistakenly, because it was > > > > used to detect compiler options and without that flag it's functionality > > > > (compiler flags detection) is broken. > > tradcpp(1): > -Werror Make warnings into fatal errors. > > There is a reason why this was removed. It wasn't mentioned in this > particular port when the patch to remove -Werror was committed, but > we have had ports abort for innocuous warnings. OK > > > > > > I see those. I feel like there must be a better way to silence those > > > unused flags. Here they are: > > > > > > cc: warning: optimization flag '-fweb' is not supported > > > [-Wignored-optimization-argument] > > > cc: warning: optimization flag '-frename-registers' is not supported > > > [-Wignored-optimization-argument] > > > > OK, but I think it is better to remove the compiler option detection > > functionality compeletely, instead of breaking it, right? > > Maybe I misunderstood you, but it sounded to me like your goal with > patching in -Werror or patching out check_gcc was to make the above > warnings go away. > If you look through the Makefile, you will find these options aren't added > by the compiler option detection, but inside the Makefile: > > $ ag -s "(fweb|frename.registers)" Quake/Makefile > 62:CFLAGS += $(call check_gcc,-fweb,) > 63:CFLAGS += $(call check_gcc,-frename-registers,) > > The actual question is if there is any value in keeping these options > (and the warnings) active or not. Given that GCC supports them, I think > the easiest way is to leave them in, whether or not clang will support > them, because we still have ports-gcc arches. I have no idea. > [...] > > > -check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > > > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) > > [...] > > > CFLAGS += $(CPUFLAGS) > > +CFLAGS += -DUSE_CRT_MALLOC > > ifneq ($(DEBUG),0) > > DFLAGS += -D_DEBUG > > CFLAGS += -g > > do_strip= > > else > > DFLAGS += -DNDEBUG > > -CFLAGS += -O3 > > -CFLAGS += $(call check_gcc,-fweb,) > > -CFLAGS += $(call check_gcc,-frename-registers,) > > -CFLAGS += $(call check_gcc,-fno-asynchronous-unwind-tables,) > > -CFLAGS += $(call check_gcc,-fno-ident,) > > +CFLAGS += -fweb > > +CFLAGS += -frename-registers > > This doesn't make any sense, you are still adding -fweb and > -frename-registers. > > If there is harm in using check_gcc, please explain more clearly. I just saying removing that -Werror will break check_gcc functionality. If you don't need check_gcc, then simply remove it, instead of breaking it. Anyway, that wasn't important at all. > [...] > > > > Server using protocol 999+ (FTE-RMQ) > > > > Exe: 21:30:40 Mar 10 2023 > > > > > > > > Vulkan Initialization > > > > Using Vulkan 1.1 > > > > Instance extensions: > > > > VK_KHR_surface > > > > VK_KHR_xlib_surface > > > > VK_KHR_get_surface_capabilities2 > > > > VK_KHR_get_physical_device_properties2 > > > > > > > > > > > > ERROR-OUT BEGIN > > > > > > > > > > > > QUAKE ERROR: Couldn't find any Vulkan devices > > > > > [...] > > > > > > I don't get an error like yours. Do vulkaninfo and vkcube work? > > > > No, they don't work too: > > $ vulkaninfo > > ERROR: [Loader Message] Code 0 : remove_all_non_valid_override_layers: > > Failed to get executable path and name > > ERROR: [Loader Message] Code 0 : setup_loader_term_phys_devs: Failed to > > detect any valid GPUs in the current config > > ERROR at > > /usr/obj/ports/vulkan-tools-1.3.239.0/Vulkan-Tools-sdk-1.3.239.0/vulkaninfo/vulkaninfo.h:237:vkEnumeratePhysicalDevices > > failed with ERROR_INITIALIZATION_FAILED > > $ vkcube > > vkEnumeratePhysicalDevices reported zero accessible devices. > > > > Do you have a compatible Vulkan installable client driver (ICD) installed? > > Please look at the Getting Started guide for additional information. > > Looks like your problem is with not having a vulkan-compatible video > device. If you want to find out why, look at your GPU (maybe share a > dmesg), and inspect glxinfo -B. > > vkquake is closely derived from quakespasm. Maybe try quakespasm if > your opengl acceleration works and you want to play quake. OK, thank you. Oh, I reported an issue for vkquake, and I might gave a bad advise: https://github.com/Novum/vkQuake/issues/645
Re: Non-standard allocations in games/vkquake
Thomas Frohwein wrote: > On Fri, Mar 10, 2023 at 08:36:06PM +0000, Ali Farzanrad wrote: > [...] > > > > Please leave in the hunk that removes -Werror > > > > > > yes, what's the reason for this being in the diff/ > > > > I thought that you've removed that -Werror mistakenly, because it was > > used to detect compiler options and without that flag it's functionality > > (compiler flags detection) is broken. > > I see those. I feel like there must be a better way to silence those > unused flags. Here they are: > > cc: warning: optimization flag '-fweb' is not supported > [-Wignored-optimization-argument] > cc: warning: optimization flag '-frename-registers' is not supported > [-Wignored-optimization-argument] OK, but I think it is better to remove the compiler option detection functionality compeletely, instead of breaking it, right? $ cat patches/patch-Quake_Makefile remove hardcoded optimization flag use standard library for allocation Index: Quake/Makefile --- Quake/Makefile.orig +++ Quake/Makefile @@ -25,14 +25,6 @@ MP3LIB=mad # which library to use for ogg decoding: vorbis or tremor VORBISLIB=vorbis -# --- -# Helper functions -# --- - -check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) - -# --- - HOST_OS := $(shell uname|sed -e s/_.*//|tr '[:upper:]' '[:lower:]') DEBUG ?= 0 @@ -51,19 +43,19 @@ LDFLAGS ?= DFLAGS ?= CFLAGS ?= -CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -Werror -std=gnu11 -MMD +CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -std=gnu11 -MMD CFLAGS += $(CPUFLAGS) +CFLAGS += -DUSE_CRT_MALLOC ifneq ($(DEBUG),0) DFLAGS += -D_DEBUG CFLAGS += -g do_strip= else DFLAGS += -DNDEBUG -CFLAGS += -O3 -CFLAGS += $(call check_gcc,-fweb,) -CFLAGS += $(call check_gcc,-frename-registers,) -CFLAGS += $(call check_gcc,-fno-asynchronous-unwind-tables,) -CFLAGS += $(call check_gcc,-fno-ident,) +CFLAGS += -fweb +CFLAGS += -frename-registers +CFLAGS += -fno-asynchronous-unwind-tables +CFLAGS += -fno-ident cmd_strip=$(STRIP) $(1) define do_strip $(call cmd_strip,$(1)); > [...] > > > > > ++CFLAGS += -DUSE_CRT_MALLOC > > > > > > Can you reference documentation about the option USE_CRT_MALLOC? I can't > > > find any in the vkquake files, nor on a quick web search. > > > > No, I just receive segmentation fault on my arm64 machine: > > $ doas pkg_add vkquake > > quirks-6.116 signed on 2023-03-09T01:36:51Z > > vkquake-1.20.3: ok > > New and changed readme(s): > > /usr/local/share/doc/pkg-readmes/vkquake > > $ vkquake > > Command line: ./vkquake > > Found SDL version 2.24.1 > > Detected 8 CPUs. > > Initializing vkQuake v1.20.3 > > Built with Clang 13.0.0 > > Host_Init > > Segmentation fault > > > > And it was about a NULL-dereferencing after a failed memory allocation. > > I tried to find the problem, but its memory management was so complex. > > I found this option on Quake/mem.c file. > > > > Even after applying my patch it is still not working on my system, but > > I don't think it is related to this port: > > $ vkquake > > Command line: ./vkquake > > Found SDL version 2.24.1 > > Detected 8 CPUs. > > Initializing vkQuake v1.20.3 > > Built with Clang 13.0.0 > > Host_Init > > Playing registered version. > > Console initialized. > > UDP4_Init: gethostbyname failed (Host name lookup failure) > > UDP4 Initialized > > UDPv6 Initialized > > Server using protocol 999+ (FTE-RMQ) > > Exe: 21:30:40 Mar 10 2023 > > > > Vulkan Initialization > > Using Vulkan 1.1 > > Instance extensions: > > VK_KHR_surface > > VK_KHR_xlib_surface > > VK_KHR_get_surface_capabilities2 > > VK_KHR_get_physical_device_properties2 > > > > > > ERROR-OUT BEGIN > > > > > > QUAKE ERROR: Couldn't find any Vulkan devices > > > > > > > ifneq ($(DEBUG),0) > > > > > DFLAGS += -D_DEBUG > > > > > -@@ -59,7 +59,6 @@ CFLAGS += -g > > > > > + CFLAGS += -g > > > > > do_strip= > > > > > else > > > > > DFLAGS += -DNDEBUG > > > > > > > > > I don't get an error like yours. Do vulkaninfo and vkcube work? No, they don't work too: $ vulkaninfo ERROR: [Loader Message] Code 0 : remove_all_non_valid_override_layers: Failed to get executable path and name ERROR: [Loader Message] Code 0 : setup_loader_term_phys_devs: Failed to detect any valid GPUs in the current config ERROR at /usr/obj/ports/vulkan-tools-1.3.239.0/Vulkan-Tools-sdk-1.3.239.0/vulkaninfo/vulkaninfo.h:237:vkEnumeratePhysicalDevices failed with ERROR_INITIALIZATION_FAILED $ vkcube vkEnumeratePhysicalDevices reported zero accessible devices. Do you have a compatible Vulkan installable client driver (ICD) installed? Please look at the Getting Started guide for additional information.
Re: Non-standard allocations in games/vkquake
Hello Thomas, Thomas Frohwein wrote: > On Thu, Mar 09, 2023 at 12:06:57PM +, Stuart Henderson wrote: > > On 2023/03/09 07:13, Ali Farzanrad wrote: > > > --- Quake/Makefile.orig > > > +++ Quake/Makefile > > > -@@ -29,7 +29,7 @@ VORBISLIB=vorbis > > > - # Helper functions > > > - # --- > > > - > > > --check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > > > > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) > > > -+check_gcc = $(shell if echo | $(CC) $(1) -S -o /dev/null -xc - > > > > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) > > > - > > > > Please leave in the hunk that removes -Werror > > yes, what's the reason for this being in the diff/ I thought that you've removed that -Werror mistakenly, because it was used to detect compiler options and without that flag it's functionality (compiler flags detection) is broken. > > > > > > > - # --- > > > - > > > -@@ -51,7 +51,7 @@ LDFLAGS ?= > > > +@@ -51,15 +51,15 @@ LDFLAGS ?= > > > DFLAGS ?= > > > CFLAGS ?= > > > > > > -CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -Werror -std=gnu11 > > > -MMD > > > +CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -std=gnu11 -MMD > > > CFLAGS += $(CPUFLAGS) > > > ++CFLAGS += -DUSE_CRT_MALLOC > > Can you reference documentation about the option USE_CRT_MALLOC? I can't > find any in the vkquake files, nor on a quick web search. No, I just receive segmentation fault on my arm64 machine: $ doas pkg_add vkquake quirks-6.116 signed on 2023-03-09T01:36:51Z vkquake-1.20.3: ok New and changed readme(s): /usr/local/share/doc/pkg-readmes/vkquake $ vkquake Command line: ./vkquake Found SDL version 2.24.1 Detected 8 CPUs. Initializing vkQuake v1.20.3 Built with Clang 13.0.0 Host_Init Segmentation fault And it was about a NULL-dereferencing after a failed memory allocation. I tried to find the problem, but its memory management was so complex. I found this option on Quake/mem.c file. Even after applying my patch it is still not working on my system, but I don't think it is related to this port: $ vkquake Command line: ./vkquake Found SDL version 2.24.1 Detected 8 CPUs. Initializing vkQuake v1.20.3 Built with Clang 13.0.0 Host_Init Playing registered version. Console initialized. UDP4_Init: gethostbyname failed (Host name lookup failure) UDP4 Initialized UDPv6 Initialized Server using protocol 999+ (FTE-RMQ) Exe: 21:30:40 Mar 10 2023 Vulkan Initialization Using Vulkan 1.1 Instance extensions: VK_KHR_surface VK_KHR_xlib_surface VK_KHR_get_surface_capabilities2 VK_KHR_get_physical_device_properties2 ERROR-OUT BEGIN QUAKE ERROR: Couldn't find any Vulkan devices > > > ifneq ($(DEBUG),0) > > > DFLAGS += -D_DEBUG > > > -@@ -59,7 +59,6 @@ CFLAGS += -g > > > + CFLAGS += -g > > > do_strip= > > > else > > > DFLAGS += -DNDEBUG > > >
Re: games/dhewm3 builds OK on x13s
Ali Farzanrad wrote: > Hi, > > I've build games/dhewm3 without a problem on my x13s laptop which is > arm64. I could run it using my owned files from GOG, however due to lack > of 3D acceleration on my system it has a very low FPS. > > Isn't it better to append arm64 to supported architectures? > > Index: Makefile > === > RCS file: /home/cvs/ports/games/dhewm3/Makefile,v > retrieving revision 1.16 > diff -u -p -r1.16 Makefile > --- Makefile 27 Nov 2022 19:18:51 - 1.16 > +++ Makefile 9 Mar 2023 10:31:55 - > @@ -1,4 +1,4 @@ > -ONLY_FOR_ARCHS = amd64 i386 > +ONLY_FOR_ARCHS = amd64 arm64 i386 > > GH_ACCOUNT = dhewm > GH_PROJECT = dhewm3 or maybe: Index: Makefile === RCS file: /home/cvs/ports/games/dhewm3/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- Makefile27 Nov 2022 19:18:51 - 1.16 +++ Makefile9 Mar 2023 10:31:55 - @@ -1,4 +1,4 @@ -ONLY_FOR_ARCHS = amd64 i386 +ONLY_FOR_ARCHS = aarch64 amd64 i386 GH_ACCOUNT = dhewm GH_PROJECT = dhewm3
games/dhewm3 builds OK on x13s
Hi, I've build games/dhewm3 without a problem on my x13s laptop which is arm64. I could run it using my owned files from GOG, however due to lack of 3D acceleration on my system it has a very low FPS. Isn't it better to append arm64 to supported architectures? Index: Makefile === RCS file: /home/cvs/ports/games/dhewm3/Makefile,v retrieving revision 1.16 diff -u -p -r1.16 Makefile --- Makefile27 Nov 2022 19:18:51 - 1.16 +++ Makefile9 Mar 2023 10:31:55 - @@ -1,4 +1,4 @@ -ONLY_FOR_ARCHS = amd64 i386 +ONLY_FOR_ARCHS = amd64 arm64 i386 GH_ACCOUNT = dhewm GH_PROJECT = dhewm3
Re: Non-standard allocations in games/vkquake
Stuart Henderson wrote: > On 2023/03/09 07:13, Ali Farzanrad wrote: > > --- Quake/Makefile.orig > > +++ Quake/Makefile > > -@@ -29,7 +29,7 @@ VORBISLIB=vorbis > > - # Helper functions > > - # --- > > - > > --check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > > > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) > > -+check_gcc = $(shell if echo | $(CC) $(1) -S -o /dev/null -xc - > > > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) > > - > > Please leave in the hunk that removes -Werror That's just a check_gcc, which is used to detect supported compiler options; without this -Werror, it adds a lot of compiler options which produces a lot of not supported warnings: cc: warning: optimization flag '-fweb' is not supported [-Wignored-optimization-argument] cc: warning: optimization flag '-frename-registers' is not supported [-Wignored-optimization-argument] > > - # --- > > - > > -@@ -51,7 +51,7 @@ LDFLAGS ?= > > +@@ -51,15 +51,15 @@ LDFLAGS ?= > > DFLAGS ?= > > CFLAGS ?= > > > > -CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -Werror -std=gnu11 > > -MMD > > +CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -std=gnu11 -MMD > > CFLAGS += $(CPUFLAGS) > > ++CFLAGS += -DUSE_CRT_MALLOC > > ifneq ($(DEBUG),0) > > DFLAGS += -D_DEBUG > > -@@ -59,7 +59,6 @@ CFLAGS += -g > > + CFLAGS += -g > > do_strip= > > else > > DFLAGS += -DNDEBUG > >
Re: Non-standard allocations in games/vkquake
Ali Farzanrad wrote: > Hi, > > I installed vkquake on my x13s laptop (arm64) but it didn't work. > After a short debug I found it is a memory allocation error (actually > NULL-dereferencing after a failed allocation). > > It seems that this port is using it's own memory allocation (mimalloc) > and after I forced it to use standard allocation functions it didn't > showed those memory problem again. > > Isn't it old enough that works fast enough without those optimizations? Sorry, last email had a wrong patch. Index: patches/patch-Quake_Makefile === RCS file: /home/cvs/ports/games/vkquake/patches/patch-Quake_Makefile,v retrieving revision 1.7 diff -u -p -r1.7 patch-Quake_Makefile --- patches/patch-Quake_Makefile23 Oct 2022 14:59:26 - 1.7 +++ patches/patch-Quake_Makefile9 Mar 2023 07:08:04 - @@ -1,27 +1,20 @@ remove hardcoded optimization flag +use standard library for allocation Index: Quake/Makefile --- Quake/Makefile.orig +++ Quake/Makefile -@@ -29,7 +29,7 @@ VORBISLIB=vorbis - # Helper functions - # --- - --check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) -+check_gcc = $(shell if echo | $(CC) $(1) -S -o /dev/null -xc - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) - - # --- - -@@ -51,7 +51,7 @@ LDFLAGS ?= +@@ -51,15 +51,15 @@ LDFLAGS ?= DFLAGS ?= CFLAGS ?= -CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -Werror -std=gnu11 -MMD +CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -std=gnu11 -MMD CFLAGS += $(CPUFLAGS) ++CFLAGS += -DUSE_CRT_MALLOC ifneq ($(DEBUG),0) DFLAGS += -D_DEBUG -@@ -59,7 +59,6 @@ CFLAGS += -g + CFLAGS += -g do_strip= else DFLAGS += -DNDEBUG
Non-standard allocations in games/vkquake
Hi, I installed vkquake on my x13s laptop (arm64) but it didn't work. After a short debug I found it is a memory allocation error (actually NULL-dereferencing after a failed allocation). It seems that this port is using it's own memory allocation (mimalloc) and after I forced it to use standard allocation functions it didn't showed those memory problem again. Isn't it old enough that works fast enough without those optimizations? Index: patches/patch-Quake_Makefile === RCS file: /home/cvs/ports/games/vkquake/patches/patch-Quake_Makefile,v retrieving revision 1.7 diff -u -p -r1.7 patch-Quake_Makefile --- patches/patch-Quake_Makefile23 Oct 2022 14:59:26 - 1.7 +++ patches/patch-Quake_Makefile9 Mar 2023 06:49:13 - @@ -1,27 +1,20 @@ remove hardcoded optimization flag +use standard library for allocation Index: Quake/Makefile --- Quake/Makefile.orig +++ Quake/Makefile -@@ -29,7 +29,7 @@ VORBISLIB=vorbis - # Helper functions - # --- - --check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) -+check_gcc = $(shell if echo | $(CC) $(1) -S -o /dev/null -xc - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;) - - # --- - -@@ -51,7 +51,7 @@ LDFLAGS ?= +@@ -51,15 +51,15 @@ LDFLAGS ?= DFLAGS ?= CFLAGS ?= -CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -Werror -std=gnu11 -MMD +CFLAGS += -Wall -Wno-trigraphs -Wno-unused-function -std=gnu11 -MMD CFLAGS += $(CPUFLAGS) ++CFLAGS += -DUSE_CRT_ALLOC ifneq ($(DEBUG),0) DFLAGS += -D_DEBUG -@@ -59,7 +59,6 @@ CFLAGS += -g + CFLAGS += -g do_strip= else DFLAGS += -DNDEBUG
Re: Tor Browser: why is there no built-in bridges?
Lets ask maintainer u...@disroot.org wrote: > > OK, I think you need to install obfs4proxy and then configure your > > Tor Browser. Here is my configuration in file ~/TorBrowser-Data/torrc: > > > ClientOnionAuthDir ... > > ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy > > DataDirectory ... > > UseBridges 1 > > Bridge obfs4 ... > > Bridge obfs4 ... > > Thank you! This works. Though I still wonder why on OpenBSD I need to know > how to configure torrc in order to get my bridges to work, where on other > os's I could just select built-in ones or paste bridges as normal. Maybe > somebody knows why this is the case? Do maintainers on other os's just do > additional configuration for their users, but OpenBSD sticks to vanilla > experience? Or was it a change to reduce the attack surface for the majority > of people who don't live in a country where Tor is blocked? > >
Re: Tor Browser: why is there no built-in bridges?
u...@disroot.org wrote: > On 2022-11-23 22:15, Ali Farzanrad wrote: > > > Hi, > > > > I'm living in Islamic Dictatorship of Iran and here I can use bridges > > provided by this Telegram bot: @GetBridgesBot > > Also you might get bridges from https://bridges.torproject.org > > Also you can purchase a VPS from any hosting like 1984.is and run your > > own obfs4 bridge there. > > > > I'm not sure about your question (why? who? how?) but I hope give you > > good alternatives. > > > > u...@disroot.org wrote: > > > > > When I click on "Configure Connection/Select a > > > Built-In Bridge", no bridges are displayed in the > > > popup. In my circumstances where I have to use a > > > bridge, this makes Tor Browser practically > > > useless. For tons of other people living in > > > repressive regimes this is true as well. Now I > > > either need to use Gmail or obtain a RiseUp > > > invite code somewhere, because Tor arbitrarily > > > decided to require one of these two email > > > providers for obtaining bridges by email. > > > Remember, Google is an ad company. Anyway, why? > > > Who? How? That's the questions I'm here for. > Thank you! Previously, Tor website was blocked by my provider, but seems > like this is not the case anymore. However, the problem is not solved: I > still cannot use Tor Browser even with the new bridges from the Tor > Browser's website. Here are the logs from Tor Browser: > 11/23/22, 19:49:51.933 [NOTICE] DisableNetwork is set. Tor will not make or > accept non-control network connections. Shutting down all existing > connections. > 11/23/22, 19:51:49.894 [NOTICE] New control connection opened from > 127.0.0.1. > 11/23/22, 19:52:03.920 [NOTICE] DisableNetwork is set. Tor will not make or > accept non-control network connections. Shutting down all existing > connections. > 11/23/22, 19:52:03.921 [NOTICE] Switching to guard context "bridges" (was > using "default") > 11/23/22, 19:52:17.285 [NOTICE] Opening Socks listener on 127.0.0.1:9150 > 11/23/22, 19:52:17.285 [NOTICE] Opened Socks listener connection (ready) on > 127.0.0.1:9150 > 11/23/22, 19:52:18.690 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:52:18.700 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:52:19.890 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:52:19.900 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:52:47.436 [NOTICE] Closing no-longer-configured Socks listener > on 127.0.0.1:9150 > 11/23/22, 19:52:47.438 [NOTICE] DisableNetwork is set. Tor will not make or > accept non-control network connections. Shutting down all existing > connections. > 11/23/22, 19:53:46.835 [NOTICE] Opening Socks listener on 127.0.0.1:9150 > 11/23/22, 19:53:46.836 [NOTICE] Opened Socks listener connection (ready) on > 127.0.0.1:9150 > 11/23/22, 19:53:47.141 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:53:47.142 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:53:48.161 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:53:48.162 [WARN] Can't use bridge at [scrubbed]: there is no > configured transport called "obfs4". > 11/23/22, 19:54:21.184 [NOTICE] New control connection opened from > 127.0.0.1. OK, I think you need to install obfs4proxy and then configure your Tor Browser. Here is my configuration in file ~/TorBrowser-Data/torrc: ClientOnionAuthDir ... ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy DataDirectory ... UseBridges 1 Bridge obfs4 ... Bridge obfs4 ...
Re: Tor Browser: why is there no built-in bridges?
Hi, I'm living in Islamic Dictatorship of Iran and here I can use bridges provided by this Telegram bot: @GetBridgesBot Also you might get bridges from https://bridges.torproject.org Also you can purchase a VPS from any hosting like 1984.is and run your own obfs4 bridge there. I'm not sure about your question (why? who? how?) but I hope give you good alternatives. u...@disroot.org wrote: > When I click on "Configure Connection/Select a > Built-In Bridge", no bridges are displayed in the > popup. In my circumstances where I have to use a > bridge, this makes Tor Browser practically > useless. For tons of other people living in > repressive regimes this is true as well. Now I > either need to use Gmail or obtain a RiseUp > invite code somewhere, because Tor arbitrarily > decided to require one of these two email > providers for obtaining bridges by email. > Remember, Google is an ad company. Anyway, why? > Who? How? That's the questions I'm here for. > >
Re: lang/python/2.7: configure error
Theo Buehler wrotes: > >> configure: error: cannot run C compiled programs. >> If you meant to cross compile, use `--host'. >> See `config.log' for more details >> [8409] Process 414 (/usr/ports/pobj/Python-2.7.12/.configure_done) exited >> with status 256. >> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659 >> '/usr/ports/pobj/Python-2.7.12/.configure_done') >> *** Error 1 in target '/usr/ports/pobj/Python-2.7.12/.configure_done' >> [30021] Process 2841 (all) exited with status 256. >> *** Error 1 in /usr/ports/lang/python/2.7 >> (/usr/ports/infrastructure/mk/bsd.port.mk:2389 'all') >> *** Error 1 in target 'all' >> >> I worked on it and found that problem is >> '/usr/ports/pobj/Python-2.7.12/bin/ld' and it is not compatible with >> '/usr/bin/ld': >> >> # rm /usr/ports/pobj/Python-2.7.12/bin/ld >> >> I don't know what might be a good patch for this problem and why this >> happened. > >I see this same error when I try to build python without having >WRKOBJDIR on a filesystem with the wxallowed mount option. > >I suspect you'll find entries like > >/bsd: ./conftest(25593): W^X binary outside wxallowed mountpoint > >in your /var/log/messages. > >To build ports that need to be marked with WXNEEDED, you need to have >WRKOBJDIR (usually /usr/ports/pobj) on a filesystem mounted with >wxallowed. > Yes, I forgot that. Thanks a lot.
Re: lang/python/2.7: configure error
Stuart Henderson wrotes: > >On 2016/11/02 16:43, Ali Farzanrad wrote: >> Hi ports@, >> >> I recently tried to build python-2.7 from ports, but I got errors: > >I suspect you are mixing -current ports and 6.0-release. > I upgraded from source few hours ago using cvsync. I rechecked for CVS/Tag in my cvs directories, and it seems that there is no CVS/Tag, thus I though I'm in current. I did sysmerge again, but no effect.
lang/python/2.7: configure error
Hi ports@, I recently tried to build python-2.7 from ports, but I got errors: # cd /usr/lang/python/2.7 && make -dA > /tmp/out 2>&1 # cat /tmp/out ... many lines ... for d in /usr/ports/pobj/Python-2.7.12/Python-2.7.12; do cp -f /usr/ports/infrastructure/db/config.guess $d; chmod a+rx $d/config.guess; cp -f /usr/ports/infrastructure/db/config.sub $d; chmod a+rx $d/config.sub; done; cd /usr/ports/pobj/Python-2.7.12/Python-2.7.12 && /usr/bin/env -i CC="cc" ac_cv_path_CC="cc" CFLAGS="-O2 -pipe" CXX="c++" ac_cv_path_CXX="c++" CXXFLAGS="-O2 -pipe" INSTALL="/usr/ports/pobj/Python-2.7.12/bin/install -c " ac_given_INSTALL="/usr/ports/pobj/Python-2.7.12/bin/install -c " INSTALL_PROGRAM="/usr/ports/pobj/Python-2.7.12/bin/install -c -s -m 755" INSTALL_MAN="/usr/ports/pobj/Python-2.7.12/bin/install -c -m 644" INSTALL_SCRIPT="/usr/ports/pobj/Python-2.7.12/bin/install -c -m 755" INSTALL_DATA="/usr/ports/pobj/Python-2.7.12/bin/install -c -m 644" YACC="yacc" OPT='-O2 -pipe -fPIC' CPPFLAGS='-I/usr/local/include' LDFLAGS='-L/usr/local/lib/' SVNVERSION=no LOCALBASE=/usr/local X11BASE=/usr/X11R6 CONFIG_SITE 3D'/usr/ports/pobj/Python-2.7.12/config.site' MKDIR_P='mkdir -p' DATADIRNAME=share ac_cv_path_GTKDOC_CHECK="" ac_cv_path_GTKDOC_REBASE="" ac_cv_path_GTKDOC_MKPDF="" LIBTOOL="/usr/bin/libtool" LIBpython2.7_LTVERSION='-version-info 0:0:0' libpython2_7_ltversion=0.0 PATH=/usr/ports/pobj/Python-2.7.12/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin ./configure --with-ensurepip=no --enable-shared --srcdir=/usr/ports/pobj/Python-2.7.12/Python-2.7.12 --with-fpectl --with-threads --enable-ipv6 --with-cxx_main --with-system-expat --with-system-ffi --prefix='/usr/local' --sysconfdir='/etc' --mandir='/usr/local/man' --infodir='/usr/local/info' --localstatedir='/var' --disable-silent-rules --disable-gtk-doc [8409] Running 414 (/usr/ports/pobj/Python-2.7.12/.configure_done) configure: WARNING: unrecognized options: --disable-silent-rules, --disable-gtk-doc configure: loading site script /usr/ports/pobj/Python-2.7.12/config.site checking build system type... x86_64-unknown-openbsd6.0 checking host system type... x86_64-unknown-openbsd6.0 checking for --enable-universalsdk... no checking for --with-universal-archs... 32-bit checking MACHDEP... openbsd6 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-icc... no checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/usr/ports/pobj/Python-2.7.12/Python-2.7.12': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details [8409] Process 414 (/usr/ports/pobj/Python-2.7.12/.configure_done) exited with status 256. *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2659 '/usr/ports/pobj/Python-2.7.12/.configure_done') *** Error 1 in target '/usr/ports/pobj/Python-2.7.12/.configure_done' [30021] Process 2841 (all) exited with status 256. *** Error 1 in /usr/ports/lang/python/2.7 (/usr/ports/infrastructure/mk/bsd.port.mk:2389 'all') *** Error 1 in target 'all' I worked on it and found that problem is '/usr/ports/pobj/Python-2.7.12/bin/ld' and it is not compatible with '/usr/bin/ld': # rm /usr/ports/pobj/Python-2.7.12/bin/ld I don't know what might be a good patch for this problem and why this happened.