In D20864#452323, @trasz wrote:

Looks good. One thing you might want to check, if you have time, is that whether we should just ignore unknown flags? I seem to remember (although I might well be completely confused here) that Linux mmap used to ignore unknown bits; does linux mremap perhaps do the same?

Either USES=autoreconf in the intel driver can be removed or the autoreconf.mk include in xorg-cat.mk can be removed, but that's just a minor thing, so please go ahead with the exp-run.

In D20724#449550, @zeising wrote:

In D20724#449462, @tijl wrote:

In D20724#449276, @zeising wrote:

I am not entirely sure what you mean here. Ports fetched directly from gitlab (or github) will require autoreconf, since when fetching arbitrary revisions, no pre-generated autotools scripts are provided.

Some projects keep pre-generated scripts in their repo.

In my experience, that is not very common. But for those, simply not depending on autoreconf in those ports solve that issue.

In D20724#449276, @zeising wrote:

I am not entirely sure what you mean here. Ports fetched directly from gitlab (or github) will require autoreconf, since when fetching arbitrary revisions, no pre-generated autotools scripts are provided.

I found two ports with USES=autoreconf and XORG_CAT: x11-drivers/xf86-input-egalax and x11-drivers/xf86-video-intel. The former isn't maintained by x11@ and is fetched from github. If such non-X.org ports are allowed to use XORG_CAT then they may be fetched from gitlab and not need autoreconf for instance, so you cannot include autoreconf.mk. If XORG_CAT is only meant for X.org ports and use by other ports is unsupported then you can keep the libtool.mk and autoreconf.mk includes (as in 9e63b55 but without " || ${USES:Mautoreconf}") and for special cases like x11-drivers/xf86-video-intel you can add "USES= autoreconf libtool" to the port Makefile instead of just USES=autoreconf.

I think the problem is you are including autoreconf.mk before setting libtool_ARGS. Try moving "libtool_ARGS?= #empty" to right before each libtool.mk include (there are two) so it's only defined if libtool is used. Then include autoreconf.mk if "USE_GITLAB && BUILDSYS == autotools" right after ". endif # ${_XORG_CAT} == <category>".

I assume you used a union in struct xucred because a pointer has a different size on different architectures? You could use something like this:

In D20411#440580, @mjg wrote:

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose.

Arbitrary symlinks are already supported. Why would mkdir be any different?

Please also bump OSVERSION so the creation of /compat/linux/dev/shm can be made conditional in emulators/linux_base-c[67]

We used to tell people to symlink /dev/shm to /tmp in pkg-message but some programs check the file system type of /dev/shm (using statfs) so after https://svnweb.freebsd.org/base?view=revision&revision=283461 /dev/shm must be tmpfs for these programs to work properly and /tmp isn't necessarily tmpfs. So I created /compat/linux/dev/shm in https://svnweb.freebsd.org/ports?view=revision&revision=424237. This also makes /dev/shm and /tmp separate namespaces like they are on Linux. The only problem I've encountered with this is when running 'command > /dev/null' as root it will create /compat/linux/dev/null as a regular file. There's no such problem when running commands as a regular user. I think the proper fix is to have a real /dev/shm directory, either by default or created by linux_common.ko. And then let linux_enable mount a tmpfs there.

This isn't about having my own rules. It's about being practical. The further PORTVERSION and RPMVERSION are apart the more difficult it is to check the current version of the port. Now, RPMVERSION is really a leftover from before Uses/linux.mk. It is only used to set DISTVERSIONSUFFIX nowadays so perhaps it is time to eliminate it and set DISTVERSIONSUFFIX directly (right after PORTVERSION).

Please keep the same style as the other Linux ports. RPMVERSION should really be up there with PORTVERSION so it's easy to check the version. It was only moved down because portlint complains so loudly about that. To move it even further down simply because of style goes against common sense though.

Our libgcc_s needs to be ABI compatible with GCC libgcc_s so it doesn't matter which one is loaded at runtime. So, if the symbols have version GCC_3.0 in GCC libgcc_s they should have that version in our libgcc_s.