How small bugs in the Microsoft linker haunt Linux, using the example of Firefox

As you know , some time ago, the Mozilla team stepped on a bug in the microsoftware linker - xul.dll was so rich that the linker fell on it. And it was not possible to build the version for platform number one (windows 32bit).

Temporarily, until clarification, “little-used” APIs were thrown out of Firefox. It happened between the 5th and 7th versions.

It will not be a surprise that the battle for the linker has continued, which is what we will be talking about.
')

- What is it, Barrymore?

For a start, circumcision was awarded the most “delicious” section for me - embedding. Mozillovtsy powerfully walked electrokosoy, leaving only a ridge for androids. Sad but true. And the incubator "new" api - so it stuck in the incubator.

But then JavaXPCOM was honored, but this was a powerful blow to my experiments.

So the introduction of firewall under Linux (and where is the microsoftware linker?) Came ales kaput had to make room and do something in the conservatory.

- Bunting, sir!

As a retaliatory move, the “outdated” gtkmozembed was chosen (as more compact for support), and I pull it from the 7th to the 14th version in the form of a patch. And the firewalk is now being assembled from raw materials, thanks to microsoftware to the crooked hands of Mozilla's “temporary” solution, which, as always, has become permanent.

As a free bonus, I survived the firefox API vigorous changes, then new interfaces for the login (prompt service), then weirdness from the principal URL, then renamed PRBool to bool, and by the 10th version the space reserve was again exhausted.

- Thames, sir!

Then began dancing with a tambourine and kamlanie. Part of the code (and quite unexpected) moved from xul.dll to firefox.exe. For example, jemalloc.

So I was very “glad” when I caught the strange firefall drops in libsqlite3. Rebuild with debugging produced a terrific dump - a crash occurred on the call

size_t je_malloc_usable_size_in_advance(size_t size); 

Wondering how this could be, I wrote a line above

 printf("strange crash below: je_malloc_usable_size_in_advance(%p) (%d)\n", je_malloc_usable_size_in_advance, size); 

and admired the long series of zeros as a function address.

- Exactly bulging the head, wah!

Examination of the raw materials of firestone 10th version reported on a hack used by the Mozilla themselves:

 LIBS+=-Wl,--whole-archive libmozglue.a -Wl,--no-whole-archive -rdynamic 

And of course, this very libmozglue.a did not get into the firefox_dev package - it was for sweetness.

In version 11 of firefox, the secret libmozglue.a self-renamed itself in libmozutil.a, and in version 13 it returned its full name.

In the same version 13, a small and inconspicuous mbft directory has moved to libmozglue. In which it was ugh and nothing - HashBytes. Without which one can be puzzled for a long time - why does it fall in libc? That's why it falls that HashKey (nsCID &) is calling HashBytes. And HashBytes, in contrast to HashString, is in .cpp. And we have a null pointer on plain C table-> op-> hash (key) - HashBytes has remained a stub.

In version 14, api for javascript was changed and even the banal JS_GC (context) turned into JS_GC (JS_GetRuntime (context)). How nice that all I need from javascript is as a function and a half!

Now I patch Firefox 14.0.1, and follow the developments. To be continued?