Issue with clang/llvm 16 and autoconf 2.13

[dbsoft]

Untested, but maybe this:

Might work, will mess with it over the weekend.

[dbsoft]

So... I was trying to figure out the best way to do this, so I tried to find out if there were more examples of hotfixes in the current mozilla repository.

Turns out, they basically forked autoconf 2.13 and include it in their tree now.

https://github.com/mozilla/gecko-dev/co ... 39c3c36d33

Would it make sense to follow suit and just import only the required parts of autoconf into our tree like they did?

[Moonchild]

Would it make sense to follow suit and just import only the required parts of autoconf into our tree like they did?

Yes.

[dbsoft]

Issue created, I should have code to test sometime this week: https://repo.palemoon.org/MoonchildProd ... ssues/2512

[Moonchild]

Thanks, it's appreciated. While forcing a no-error on it will obviously work in the meantime, I'm sure they will eventually just remove that option since they're making a point to suddenly trip over it after 25+ years.

[athenian200]

Turns out, they basically forked autoconf 2.13 and include it in their tree now.

https://github.com/mozilla/gecko-dev/co ... 39c3c36d33

Would it make sense to follow suit and just import only the required parts of autoconf into our tree like they did?

That's actually what I was afraid we were going to have to do, but I was thinking it was going to be more of a nightmare than it was. I assumed autoconf was written in C and that it would have to be built in order to be used. But if all we are talking about is bringing in more m4 modules, we already have m4 as a build dependency and have dozens of m4 modules in-tree already...

So forking autoconf basically just means we have the m4 modules we've been using for years in our own tree, and it's that simple? In that case it sounds like a no-brainer... thanks for looking into it, I've been studying for final exams the last two weeks and haven't had much time to do anything UXP related.

Just be aware, I have a trick somewhere in the build system where I use a TOOLCHAIN_PREFIX to have the build system look for gm4 instead of m4, because Solaris m4 doesn't support the required functionality and it needs to use the GNU version... so I will have to test this out. The hidden dependency on m4 was a major pain point when porting to Solaris/illumos initially because it resulted in inexplicable failures of most autoconf stuff that wasn't being done through moz.configure.

[dbsoft]

Just be aware, I have a trick somewhere in the build system where I use a TOOLCHAIN_PREFIX to have the build system look for gm4 instead of m4, because Solaris m4 doesn't support the required functionality and it needs to use the GNU version... so I will have to test this out. The hidden dependency on m4 was a major pain point when porting to Solaris/illumos initially because it resulted in inexplicable failures of most autoconf stuff that wasn't being done through moz.configure.

Yeah already handled that, but thanks! Had the same problem on FreeBSD, not sure if the m4 on FreeBSD would actually work, but it checks the version and fails that check.

https://repo.palemoon.org/dbsoft/UXP/co ... e54396f025

[athenian200]

https://repo.palemoon.org/MoonchildProd ... 3ae9233c9a

Yeah, I did just see your commit. I was worried it might conflict with what I did here, but since the old-configure.in script is just using m4 blindly without pulling in a variable to check which version it should be using, it should work fine for now. I was worried it might make it something like "ggm4," but it looks like it should be able to wait until I can set it up to use the M4 environment variable instead of just using the m4 command with a TOOLCHAIN_PREFIX.

What you've done is probably how I should have done it in the first place, but I wasn't very knowledgeable about autoconf at the time or how it checked for programs.

Anyway, this is shaping up to be a good move overall... because now the dependency on m4 is made explicit.

[dbsoft]

Along the same lines would it make sense to port this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1717088

I remember having issues getting Epyrus building on Windows due to these missing headers?