I created a Solaris/illumos port of UXP out of boredom.

Talk about code development, features, specific bugzilla bugs, enhancements, patches, and other highly technical things.

Moderator: satrow

Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific referenced Bugzilla bugs, mercurial, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Most "bug reports" do not belong in this board and should initially be posted in Community Support or other relevant support boards.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-11, 00:22

Yeah, I know exactly what you're talking about. I wasn't a fan of that workaround myself, it didn't make any sense to me at all that this was needed when the values in old-configure.in appear to get passed through just fine. So I removed it and as you can see...

MOZ_PHOENIX, MOZ_PHOENIX_EXTENSIONS, MC_PALEMOON, MOZ_PERSONAS, and MOZ_SERVICES_COMMON are all missing from the list. In Interlink's case, it was even worse because MOZ_MAILNEWS wasn't defined and it was building an empty shell that mysteriously exited without crashing. So what we do know is it's not Pale Moon specific and the same issue affects any application using confvars.sh and configure.in to pass something through the UXP build system. Everything defined in old-configure.in, a moz.build file, or a moz.configure file goes through fine, AFAIK.

I actually tested something on Linux Mint too. I tried to get those values to be false on Linux by removing stuff from confvars.sh and configure.in, seeing if I could replicate the same failure mode I was seeing on Solaris. For some weird reason it didn't seem to work, it acted like they were still there and the build succeeded.
Off-topic:
Incidentally, I'm apparently banned from Freenode because my Internet was out and I left Pidgin or something running on Desktop. It reconnected automatically while I was still using my mobile hotspot to the same service I was already using, and well...
Image
I know because the day and time listed on DroneBL is the exact day and time my Internet came back on after a three-day outage. I got banned from a bunch of stuff shortly after and had no clue why until now.
Attachments
config.txt
This is config.status, renamed for phpBB's benefit.
(36.6 KiB) Downloaded 8 times

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 00:31

Ok, give me the console output for mach configure. Also, want me to talk to freenode people?
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-11, 00:52

Sure, I just piped it into this file. And yeah, that would help me out.
Attachments
config2.txt
(31.25 KiB) Downloaded 7 times

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 01:13

Code: Select all

 0:12.59 m4:/export/home/athenian/Downloads/git/UXP/build/autoconf/altoptions.m4:30 bad macro name
 0:12.59 define(# Check whether --enable- or --disable- was given.
 0:12.59 if test "${enable_patsubst(, -, _)+set}" = set; then
 0:12.59   enableval="$enable_patsubst(, -, _)"
 0:12.59 
 0:12.59 fi
 0:12.59 ,MOZ_ARG([--enable-]translit([$1],[_],[-]))AC_ARG_ENABLE([$1], [$2], [$3], [$4]))
And because of that it doesn't continue on to reading the application specific configure.in and maybe other things.

http://xref.palemoon.org/uxp-trunk/sour ... re.in#4146

This is direct fallout from mozconfigure being introduced and taking over parts. They obviously didn't test lines 23-31 with Solaris.

Also as a side note: Pick a different gcc version and stay the hell away from gcc 6 for fuck sakes.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 01:49

Sigh.. Mozilla via Thunderbird's suggestion was to not build essentually old and insecure versions and the solution? Move application specific configure.in to moz.configure. See Bug 1554468

FUCKING UNACCEPTABLE

I want to know why this fails on Solaris M4 but not linux and only on the tempfile generated.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-11, 02:18

I'm not using GCC 6, those failures are quoting the wrong version. I'm using GCC 7, but the system tries to use GCC 6 by default even though I don't have it installed.

Also, I just tested replacing m4 with gm4... everything works now. The problem is that the script is just hard-coded to use whatever m4 the system picks up rather than specifically checking for GNU M4. On Solaris and many other Unix systems, the default m4 isn't the GNU one, so even if it's available, it picks up the wrong one.

It should be easy to fix now that we've realized that was the problem, but I never thought to check for it because my system has GNU M4 installed, configure insisted, they just invoked the wrong one after explicitly telling me to install GNU M4.

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 02:30

Well good.. least my half-assed build system skills are still good then.

Make sure to document your efforts and keep them handy for build instructions later on.

Btw, we figured out Bug 1554468 in what an hour? Fuck the mozis anyway.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-11, 04:28

I really appreciate your help, Tobin. It's nice to have someone that knows the build system a bit better give me an idea of what to look for, I've been kind of trying to figure it all out as I go along, and sometimes odd issues like this take the longest to figure out. It's not the ones you would think, like finding bugs in assembler code or figuring out why something segfaults every time it tries to allocate memory, but the stuff you wouldn't even think to check for at first.

Anyway, the simplest fix for this that comes to mind is simply telling it to use ${TOOLCHAIN_PREFIX}m4. I already have --with-toolchain-prefix=g because of readelf being greadelf. The other two options are for me to either rewrite subconfigure.m4 and altoptions.m4 as POSIX M4 scripts (so they don't depend on GNU M4), or else make absolutely sure configure fails if it can't find a GNU version of m4, and invokes the GNU M4 it finds.

Seriously, though, most of my work just involved fixing Mozilla's POSIX compliance issues where they just used a non-portable Linux approach over something that would work on any Unix (including Linux), so I'm really not too surprised this wound up being the problem. Things like assuming the system sh is always configured to act like bash in the mozconfig loader without explicitly invoking bash, using a GNU extension to grep for a script without explicitly requiring/invoking GNU grep, using malign assuming it's always the same as posix_malign, etc... most of the reasons why this didn't work before were actually rather silly and could have been avoided if Mozilla had cared to write portable code.

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 09:30

I would avoid messing too much with the build systems if we can avoid it. They are tricky things and even though I been learning about autohell/moz* for almost six years now even I have only scratched the surface.

Maybe one day we can get it sorted but the important thing is with the right poking about we worked around them in the here and now.

Now the testing begins both on Solaris but also make sure you didn't hose Windows and the Linux. Probably Macintosh too but nothing I can do about that atm.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 15:54

Did a linux build because I run the linux now.. Your changes don't seem to impact it at all on the surface so that is good. Of course closer inspection of all the code changes is warranted. However, it is all very clean compared to the mostly busted stuff we removed.. So you have already accomplished a lot and indeed managed to make me personally interested.

I think if we can be this efficient about it we could likely look at reabsorbing this back up the line soonish. We want to take this in at the start of a development cycle rather than trying to fudge it in at the end of one that got paused by the Pale Moon 10 year anniversary of not doing anything AT ALL in celebration for a month. But I am behind you for this. I am both impressed with what you have managed to work out in such a short period of time and excited that something cool will come of this for all of us. So I am all for it!

EDIT: Freenode was no help.. So can you go to dronedb and resolve it?
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-11, 19:06

Yeah, honestly I think just having ${TOOLCHAIN_PREFIX} there as an option is the least invasive and changes the functionality the least, because it does exactly what it does now if you don't set a toolchain prefix. I think there's nothing wrong with expecting people to have GNU M4 somewhere on the system since we already require GNU make. The weird thing is, it handles the case of make being gmake fine, but not with other stuff.

I was testing against Linux while building this to see what it should do, and I would be able to setup a Windows build environment to ensure that works as well, but I have no access to a Macintosh, so I can't test that platform. Yeah, I can definitely understand wanting to do this closer to the beginning of a cycle.
Off-topic:
I went to DroneBL, and they said they'd remove it but it might take a bit of time. I think that this can be resolved since it's not like there's a pattern of reports, just this one-off that's easily explained.

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-11, 19:41

Well I hope to see you soon dude.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

User avatar
SpockFan02
Astronaut
Astronaut
Posts: 505
Joined: 2017-09-24, 16:35
Location: Mak pupulusšum, California

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by SpockFan02 » 2019-10-13, 07:38

Built Pale Moon from your repo without problems and it works fine on Mac.

User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-15, 07:06

SpockFan02 wrote:
2019-10-13, 07:38
Built Pale Moon from your repo without problems and it works fine on Mac.
Thank you, SpockFan02! I appreciate you testing that for me.

Anyway, the last wrinkle that I've been trying to solve is finding a way to avoid relying on LD_LIBRARY_PATH in some script in the final package, which I know is generally a bad practice. So far to get ./mach run to actually run, I've had to type something along the lines of:

Code: Select all

export LD_LIBRARY_PATH="/usr/gcc/7/lib/amd64:/export/home/athenian/UXP/obj-release/dist/bin"
So the first thing I figured out was how to insert $ORIGIN into the runpath. It turns out it's insanely hard to do, and that I also didn't need to do it because at some point the runtime linker started searching there automatically without needing that compiled into the path. But if you ever need to do it for some reason, you have to do it like this:

Code: Select all

-R'\$\$ORIGIN'
You have to put the whole thing in quotes, use two $ symbols to avoid having it picked up by gmake as a script variable, and use backslash to escape each $ symbol so the shell doesn't interpret it as a shell variable when it hits the command line. That's what you have to do to get $ORIGIN compiled into the runpath, otherwise it will be mangled beyond recognition and yield something totally wrong.

But it turns out that I needn't have worried, everyone else was having the same problem and in later versions of Solaris they pretty much just made the runtime linker search $ORIGIN by default so people don't have to deal with this. They had a lot of fun with this a while back, though... https://bugzilla.mozilla.org/show_bug.cgi?id=259945

It turns out though, that you need LD_LIBRARY_PATH to make ./mach run work, but not in a packaged version. The reason is because of how symlink resolution is handled. The $ORIGIN flag uses the actual location of all the libraries, not the location of the symlink, therefore all the symlinks in dist/bin won't work unless you assert an LD_LIBRARY_PATH. However, this won't matter in the packaged version because you'll have the actual .so files there instead of symlinks. So that has to be kept in mind.

The other wrinkle that's interesting is that it turns out /usr/gcc/7/lib/amd64 is correctly inserted into the runpath of every shared library already, and I shouldn't need to add that to my runpath at all. The reason I've been needing to add it is because of the runpath of libxul.so having a silly problem. By typing:

Code: Select all

elfedit -r -e 'dyn:value runpath' libxul.so
You can see that /usr/lib/amd64 is ahead of /usr/gcc/7/lib/amd64 in the runpath. Why is that a problem? Well, the output of ldd reveals why. It looks like this at a key point:

Code: Select all

libstdc++.so.6 =>	/usr/lib/amd64/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4.21) =>	(version not found)
So it's picking up the wrong libstdc++.so.6 from /usr/lib/amd64, and that's why LD_LIBRARY_PATH being set to /usr/gcc/7/lib/amd64 fixes it. However, libxul.so is the only shared object that appears to have this problem with its runpath, all the others seem fine. Aside from LD_LIBRARY_PATH, I could also use a feature in crle, which is the Solaris equivalent of ldconfig. It works like this:

Code: Select all

crle -64 -a /usr/lib/amd64/libstdc++.so.6 -o /usr/gcc/7/lib/amd64
It basically tells the linker to look in /usr/gcc/7/lib for an alternative object anytime something asks for /usr/lib/amd64/libstdc++.so.6, which has the advantage of not altering the search path for any other file. But it's still a system-wide setting and really not a lot better than using LD_LIBRARY_PATH, though at least it's more targeted. In theory, you could actually compile the application to use a custom ld.config that you bundle with the application by using the -c option to the Solaris linker, but in practice it would be really hard to figure out a reliable path for that config file to compile into the binaries (probably it would end up having to be placed in somewhere like $HOME/.moonchild productions), and make sure the flag wasn't used along with several incompatible flags in the makefiles at various points. This setup would probably still require a first-time run script just like an LD_LIBRARY_PATH script would though, but with the advantage that it would only have to be run once and from then on you could just run the palemoon executable directly.

But by far the best solution I've been able to come up with, is this one.

Code: Select all

elfedit -e 'dyn:runpath /usr/gcc/7/lib/amd64:/usr/lib/amd64' libxul.so
https://blogs.oracle.com/solaris/changi ... ncluded-v2

From this article, I found out that Solaris actually went ahead and allocated extra space in the dynamic string tables of their ELF files so that people could edit the runpaths of them without recompiling, so this is actually fairly safe and effective. What this does is put /usr/gcc/7/lib/amd64 ahead of /usr/lib/amd64 in the search path, so that libxul.so no longer picks up the wrong version of libstdc++.so.6, and therefore after extracting the the package created with ./mach package to your home directory...

You will finally be able to just run ./palemoon and have everything work without any initial setup script, just like it does on other operating systems. Sure, this isn't quite as good as actually finding a way to compile libxul.so so it doesn't have the wrong search path in the first place (which I should really do), but the elfedit technique makes the issue only a concern for the person packaging a program for Solaris. It makes the search path issue in the code end up being more or less invisible to the end user and doesn't require them to use any scripts on their end as a workaround.

User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-18, 02:43

Well, as an update, I finally got a Windows build environment setup to see if my code breaks anything on Windows. My modified UXP code seems to build and run in both 32-bit and 64-bit Windows environments. I always wondered why I never saw a lot of Powershell or Windows-specific scripts in the code, and now I know... apparently it uses MinGW! Which means aside from nmake and the C compiler, it still uses the GNU toolchain.

Anyway, I did find a way to fix the binary runpaths without just using elfedit after the fact, but it involved using architecture-specific build flags for the GCC library location.

https://github.com/athenian200/UXP/comm ... 030e99f057

It's kind of ugly, but it works. Knowing the GCC root wouldn't help because that root would still require /lib or /lib/amd64 at the end of it.

I also tested building on Oracle Solaris. It requires one additional ${TOOLCHAIN_PREFIX} flag that OpenIndiana didn't require, due to it using a slightly inferior implementation of sed as default. Switching to gsed fixes all the problems, though.

However, even though it seems to build/run fine on both versions with the same modifications, it's worth noting that they cannot share binaries due to using a slightly different libc version. Attempting to run a binary compiled on OpenIndiana or any other Illumos distribution on Oracle Solaris results in this:

Code: Select all

libc.so.1 (ILLUMOS_0.26) =>	(version not found)
libc.so.1 (ILLUMOS_0.5) =>	(version not found)
While running a binary compiled on Oracle Solaris on an illumos distribution results in this:

Code: Select all

libc.so.1 (SUNWpublic) =>		(version not found)
Even their libstdc++.so.6 versions are compatible, though. So the libc versioning issues are literally the only reason binaries from one don't work on the other. But the good news is, everything builds pretty much exactly the same on both platforms and all I have to do is build Oracle Solaris versions and illumos versions of the binaries from the same source code (as I already have both build environments setup anyway).


User avatar
athenian200
Fanatic
Fanatic
Posts: 147
Joined: 2018-10-28, 19:56
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by athenian200 » 2019-10-18, 19:45

It looks like the issue you just opened for Solaris is a meta issue, and based on my understanding of the word "meta," it sounds like that means sub-issues would be opened up under different numbers and reference that one so it becomes a list of all the Solaris-related support issues making it easier to look in one place to track them all down.

So, yeah... this is the part I've been concerned about. I'm pretty good at getting stuff to work, but I don't have a lot of experience with commit procedures, properly tagging issues, or anything like that. So, I knew I needed to make sure this didn't break any other build targets right off the bat, and also needed to add explanatory comments to the code and justify my changes while explaining the possible alternatives in commit comments. But beyond that, I have to admit that I don't have a clear idea of what sort of work needs to be done from here on out. Well, I guess it kinda goes without saying that porting UXP to other operating systems probably isn't a Good First Issue... but it just sort of happened that way.

Also, I looked into the situation with Solaris/illumos. Apparently Solaris 10 and earlier binaries DO work on both systems, but they've both made minor changes to their system libc since then, so anything compiled on a modern version of either system is binary incompatible with the other (though both share backwards compatibility). For a more understandable analogy, it would be like if Microsoft open sourced Windows XP through Vista, and then got acquired by IBM who made the code closed again for Windows 7 and later. Then let's say the open source Windows got renamed ReactOS or something. You would probably be able to target both systems by writing code that works on XP/Vista for several years afterwards, but at some point there would be so many features missing that had been added to both forks that you'd eventually want to have separate binaries to take advantage of them.

So in theory, if it's important to target both systems with a single binary, a Solaris 10 build environment would accomplish that for a few more years, at the expense of having to pretend like any features added since then by either party basically don't exist (and in many cases they've made essentially the same changes despite using incompatible versioning symbols). But honestly, I think they want to be regarded as separate operating systems with a shared heritage at this point rather than being held back by the feature set of Solaris 10 for the rest of their existence.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 24805
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by Moonchild » 2019-10-18, 20:17

Dealing with a meta issue is simple -- You've done a lot of work on the Solaris/Illumos compatibility -- but that work done addresses several different issues; You can make new issues for each individual part you've fixed, and just state in the opening description of the issue that it "Blocks #1251" -- Github will then automatically reference the issue in the meta issue and it's easy to keep an overview there what has been solved or not. Any specific discussion about the bugfixes should be in the individual issues opened.

Also, it's probably best to build on each O.S. to target them, since as you say, they are to be considered to just have a common-ancestor, but that ancestor has been superseded.
"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne
Image

User avatar
New Tobin Paradigm
Off-Topic Sheriff
Off-Topic Sheriff
Posts: 6168
Joined: 2012-10-09, 19:37
Location: Sector 001

Re: I created a Solaris/illumos port of UXP out of boredom.

Unread post by New Tobin Paradigm » 2019-10-18, 23:00

For specific instance you would perhaps for the final clean series of changes for each major component as say three commits each.. code changes, build system, tests (if you care).. for each application, js, dom, security, xpcom, etc

OR it could be as you have done it already and that issue I created is just tracking.. Either way we need at least ONE issue and I created it for you.

Just depends which is more important in this case.. The development progression or the ability to backout changes to specific components and redo them later on. There are pros and cons to both strategy.
Image
- Old and insecure for legitimate and reasonable purposes. -
http://binaryoutcast.com/ | http://thereisonlyxul.org/ | Freenode #binaryoutcast

Post Reply