Looks like this thread got off the rails (even for off-topic which isn't where it is)
Yes, but being off the rails is not the thread's fault, nor is the thread itself off-topic.
Looks like this thread got off the rails (even for off-topic which isn't where it is)
Tag i got that. I am building aarch64 box just for the cause. Of course I need to build the beta on my own.
make then do 'add ons' like make package (for use on other machines), make reinstall for daily driver.
Normally, you'll restrict archs only when the port is proven to fail on some arch. For testing the build on e.g. aarch64, I could certainly help. If there are issues at runtime, eventually someone will report that on bugzilla. Then it's still time to add some arch restriction if the issue can't be resolved.
General school of thought: "brain > portfmt/portclippy > portlint". Meaning: they're linters, they're very useful for finding actual issues, you should always have a look at what they have to say. And if possible, getting them completely silent is perfect. BUT: There will always be situations where you won't follow their recommendations.Checking the port with portlint: There are some warnings, but none error; F.e. one warning is the direct use of "autoconf2", which should be used by a variable. Spent much time in that - without success (but it's time to re-check this after several months again). And other ports do the same. Or defining a license - well, thats not so simple as saying "GPL2". Etc. And I found out that portlint isn't always wiser
Without having looked at the port, just one remark: In cases where it doesn't matter technically,
DISTVERSION is preferred over PORTVERSION.gitup ports) told me that it is unsupported on FreeBSD 13.2 … think that's a temporary thing… 0:49.32 In file included from Unified_cpp_gfx_skia1.cpp:137:
0:49.33 /usr/ports/www/seamonkey/work/seamonkey-2.53.17b1/gfx/skia/skia/src/core/SkCpu.cpp:84:27: error: use of undeclared identifier 'getauxval'
0:49.33 uint32_t hwcaps = getauxval(AT_HWCAP);
0:49.33 ^
0:50.56 1 error generated.
0:50.60 gmake[6]: *** [/usr/ports/www/seamonkey/work/seamonkey-2.53.17b1/config/rules.mk:758: Unified_cpp_gfx_skia1.o] Error 1
0:50.60 gmake[5]: *** [/usr/ports/www/seamonkey/work/seamonkey-2.53.17b1/config/recurse.mk:74: gfx/skia/target] Error 2
0:50.61 gmake[5]: *** Waiting for unfinished jobs....#elif defined(SK_CPU_ARM64) && __has_include(<sys/auxv.h>)
#include <sys/auxv.h>
static uint32_t read_cpu_features() {
const uint32_t kHWCAP_CRC32 = (1<<7);
uint32_t features = 0;
uint32_t hwcaps = getauxval(AT_HWCAP);
if (hwcaps & kHWCAP_CRC32) { features |= SkCpu::CRC32; }
return features;
}
github.com
github.com
I guess that's related to your other thread?
Well, since you've done all the legwork... Try replacingLearning experience for a newbie here:
Remove HAVE_GETAUXVAL check for FreeBSD by pkubaj · Pull Request #410 · xiph/flac
FreeBSD doesn't have getauxval().
⚙ D12743 Make elf_aux_info() as public libc function.
reviews.freebsd.org
BUG: getauxval declaration invalid, causes compile issues · Issue #21386 · numpy/numpy
Describe the issue: Trying to install numpy, (main branch) on FreeBSD/aarch64 (aka arm64), using clang, and I get the following compile error: INFO: cc: numpy/core/src/common/npy_argparse.c [133/18...
uint32_t hwcaps = getauxval(AT_HWCAP);uint32_t hwcaps = elf_aux_info(AT_HWCAP, (void *)&hwcaps, (int)sizeof(hwcaps));Awesome! If you're interested in submitting a patch upstream, a proper change would look like this:
uint32_t features = 0;
#ifdef __FreeBSD__
uint32_t hwcaps = elf_aux_info(AT_HWCAP, (void *)&hwcaps, (int)sizeof(hwcaps));
#else
uint32_t hwcaps = getauxval(AT_HWCAP);
#endif
if (hwcaps & kHWCAP_CRC32) { features |= SkCpu::CRC32; }
return features;
And I wanted to see seamonkey in the official ports. 
8:55.39 /usr/include/c++/v1/string:1726:9: error: call to '__throw_out_of_range' is ambiguous
8:55.58 _VSTD::__throw_out_of_range("basic_string");
8:55.58 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
8:55.58 /usr/include/c++/v1/__config:826:15: note: expanded from macro '_VSTD'
8:55.58 #define _VSTD stdjmos port work has been working for years.
Build Configuration
SeaMonkey 2.53.17 beta 1 - 20230801012213
The latest information on building SeaMonkey can be found at https://www.seamonkey-project.org/dev/.
Build platform
Target
x86_64-unknown-freebsd13.1
Build tools
Compiler Version Compiler flags
/usr/bin/clang -std=gnu99 13.0.0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pipe
/usr/bin/clang++ 13.0.0 -Qunused-arguments -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -I/usr/local/include -Qunused-arguments -Wall -Wbitfield-enum-conversion -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wshadow-field-in-constructor-modified -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wfloat-overflow-conversion -Wfloat-zero-conversion -Wloop-analysis -Wc++1z-compat -Wc++2a-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wtautological-overlap-compare -Wtautological-unsigned-enum-zero-compare -Wtautological-unsigned-zero-compare -Wno-inline-new-delete -Wno-error=pessimizing-move -Wno-error=self-move -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wno-error=return-std-move -Wno-error=atomic-alignment -Wno-error=deprecated-copy -Wno-error=unused-but-set-variable -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -O2 -O3 -fomit-frame-pointer -funwind-tables
/usr/local/bin/rustc 1.70.0
Configure options
--enable-application=comm/suite --disable-tests --enable-release --disable-debug-symbols LLVM_CONFIG=/usr/local/bin/llvm-config13 --enable-alsa --disable-webrtc MAKE=/usr/local/bin/gmake --enable-dbus --disable-gconf --enable-install-strip --enable-official-branding --enable-strip --disable-updater --prefix=/usr/localI agree that SeaMonkey is using an old branch but I think it is much higher now.
User agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.17make in the ports directory on a blank machine). Or included a bunch of patches. But I wanted the port to include SeaMonkey "as is", and not something heavy modified; And if the code had to be fixed I first got in touch with the upstream instead of using patches (IMO a patch should only be necessary when the upstream can’t solve it for other reasons - or is unwilling to do so; and if I’m reading the porters handbook that’s how it should be: patches only if FreeBSD specific). Or wanted a "solution" for a not existing problem added many errors (not: warnings) by checking the port with portlint. And much more…mach commands, or are you using the compiler directly? Are you using a port you found, or are you using the source archive as is? And which version are you trying to compile on which environment, which packages are installed, what have you executed to get there etc.; And: Is there a reason why you’re compiling it as I’m offering in this thread binary packages for quarterly and latest?document.getElementById() call - nothing more; discussing with people of that level I’ve been told far to often that I have no clue about how things work today). Creepy. Sad. What SeaMonkey can’t: CSS for scrollbars (IMO not a dealbreaker), gaps on gridded templates (that’s something I’m really missing - but how many web developers know about that stuff? don't recognize that in the wild beside my own work; but still: grids are generally working), the "lazy-loading" parameter for images (simply solvable), and … there’s one more, but does not occur to me right now (wasn’t a big thing, too). But there is no reason to exclude SeaMonkey - that’s always a lack of knowledge.Yes, you're right, I'm not concrete enough.
Basically I'm just expressing frustration that I've build port a half a year ago and now there are breaking changes somewhere. And I even don't clearly understand what has changed. I've tried another compiler, same error. So I guess I have to try build the latest port, provided on your page. I just didn't found link inside the thread at the moment of writing. And I usually don't build the whole suite, only the mail client, so I have to make diff between last port with my changes and yours. That kind of unnecessary work frustrates too. But thanks that you are keeping up with support of Thunderbird. I honestly don't imaging any mail client I could migrate to.Just noticed, that in the new version of your port there is a hardcode clang13. So it may be the issue after all. Otherwise what's the point to not keep up with default version.
Were you told you need to use /usr/ports/Mk/bsd.gecko.mk for SeaMonkey ?