Link to already ported libraries

[SilvanScherrer]

in http://svn.netlabs.org/ports are already some ported mozilla libs. those repos should contain the same code in the end. this makes delivering as dll way easier.

[dmik]

Yes, we will have components reused in other projects as separate RPMs. The source will be the same (this repository). We will also create RPMs for all dependencies like fontconfig, freetype etc. Fontconfig will most likely be taken from the Dave's repository: http://bitbucket.org/dryeo/mzfntcfgft.

[dmik]

Libraries to consider are:

• NSS (nss*.dll) (DONE)
• NSPR (nspr.dll, plc.dll, plds.dll) (DONE)
• FREETYPE (freetyp6.dll) and FONTCONFIG (fntcfg2.dll) (DONE)
• JPEG (jpeg.dll) (POSTPONED, see commends below)(DONE)
• PNG (png*.dll) (POSTPONED, see commends below) (DONE)
• LIBFFI (seems to be a static library)
• SQLITE3 (--enable-system-sqlite), we have 3.7.2, FF needs 3.9.1

This list is to be clarified over time.

[dmik]

Freetype and fontconfig are being already used in my recent builds of Firefox and all seems to work. This will be part of the Beta 4 release (soon). I will also try to link Firefox against the system jpeg and png libraries and if it works, this will also be part of Beta 4. I've also updated the list in comment 3 with some more libraries.

[dmik]

@ydario could you please comment here on how and when the current RPM versions of NSS, NSPR and LIBFFI are used? We have the sources for those in both ports and in the Mozilla repo which is somewhat ambiguous. We should have a single source for these libraries (and then I will use it Mozilla as well).

[ydario]

libffi 3.0.12 nss 3.12.8 npsr 4.8.6

I don't remember who uses libffi, but nss&nspr are used by AOO and rpm. They are taken from the the mozilla tree about 4 years ago. I think they can be updated to latest releases (dlls are prefixed by letter K), or we can rebuild AOO&rpm with newer versions taken from firefox build. I doubt this code changed so much in the years, so I think we can move it on.

[dmik]

Our RPM libpng is not sufficient for Mozilla, it claims this:

configure: error: --with-system-png won't work because the system's libpng doesn't have APNG support
------ config.log ------
configure:14731: checking for localeconv
configure:14759: gcc.exe -o conftest.exe -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h -lp
thread  -Zomf -Zmap -Zlinker 'DISABLE 1121' -Zhigh-mem conftest.c -lmmap -lurpo -Zomf 1>&5
configure:15497: checking for YASM assembler
configure:15503: checking for yasm
configure:15841: checking for png_get_valid in -lpng
configure:15860: gcc.exe -o conftest.exe -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h -lp
thread  -Zomf -Zmap -Zlinker 'DISABLE 1121' -Zhigh-mem conftest.c -lpng  -lmmap -lurpo -Zomf 1>&5
configure:15882: checking for png_get_acTL in -lpng
configure:15901: gcc.exe -o conftest.exe -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h -lp
thread  -Zomf -Zmap -Zlinker 'DISABLE 1121' -Zhigh-mem conftest.c -lpng  -lmmap -lurpo -Zomf 1>&5
weakld: error: Unresolved symbol (UNDEF) '_png_get_acTL'.
weakld: info: The symbol is referenced by:
    D:\Temp\ccGt3Aaf.o
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _png_get_acTL is an undefined reference
file D:\Temp\ccGt3Aaf.o(ccGt3Aaf.o): undefined symbol _png_get_acTL
configure: failed program was:
#line 15890 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char png_get_acTL();

int main() {
png_get_acTL()
; return 0; }
ERROR: The following command failed with error code 1:
D:/Coding/mozilla/master/configure --disable-tests --with-system-png --enable-official-branding --disable-tests --disable-debug --enable-debug-symbols --enable-
optimize=-O3

[dmik]

The RPM build of libjpeg is not sufficient as well:

checking for jpeg_destroy_compress in -ljpeg... yes
configure: error: Insufficient JPEG library version for --with-system-jpeg
------ config.log ------
configure:14705: gcc.exe -c -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h conftest.c 1>&5
configure:14731: checking for localeconv
configure:14759: gcc.exe -o conftest.exe -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h -lp
thread  -Zomf -Zmap -Zlinker 'DISABLE 1121' -Zhigh-mem conftest.c -lmmap -lurpo -Zomf 1>&5
configure:15497: checking for YASM assembler
configure:15503: checking for yasm
configure:15562: checking for jpeg_destroy_compress in -ljpeg
configure:15581: gcc.exe -o conftest.exe -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h -lp
thread  -Zomf -Zmap -Zlinker 'DISABLE 1121' -Zhigh-mem conftest.c -ljpeg  -lmmap -lurpo -Zomf 1>&5
configure:15621: gcc.exe -c -march=i486 -mtune=i686 -std=gnu99 -fgnu89-inline -fno-strict-aliasing -Zomf -pthread -idirafter D:/Tools/OS2TK45/h conftest.c 1>&5
configure: In function 'main':
configure:15615:23: error: #error "libjpeg-turbo JCS_EXTENSIONS required"
configure: failed program was:
#line 15606 "configure"
#include "confdefs.h"
 #include <stdio.h>
                     #include <sys/types.h>
                     #include <jpeglib.h>
int main() {
 #if JPEG_LIB_VERSION < 62
                     #error "Insufficient JPEG library version (62 required)."
                     #endif
                     #ifndef JCS_EXTENSIONS
                     #error "libjpeg-turbo JCS_EXTENSIONS required"
                     #endif

; return 0; }
ERROR: The following command failed with error code 1:
D:/Coding/mozilla/master/configure --disable-tests --with-system-jpeg --enable-official-branding --disable-tests --disable-debug --enable-debug-symbols --enable
-optimize=-O3

It looks like the Mozilla guys use their own patched versions of LIBPNG and LIBJPEG. And given that these libraries are relatively small and statically built into XUL.DLL, we will leave them as is for now.

[dryeo]

On 03/09/15 10:00 AM, ydario wrote:

libffi 3.0.12

Libffi is supposed to be used by GCC and Python. Be aware that libfii is broken, I just did a quick hack using the Windows calling conventions to get around the build break at the time and later enigmail had a testcase that failed. Also at the time I had no working tk/tcl libc port to run the testsuite. The purpose of libffi is to allow calling native code from scripts and other non-native code, for Mozilla this would allow extensions to call xul functions instead of having to recompile the extension every release like has to be done with Lightning

[dryeo]

One question is how using more DLLs affect shared memory. Even with high shared memory some people are having problems. Here I have SM marked to load high but not TB as I was getting traps and shared memory leaks away over a couple of days. On the other hand, back when we could build Mozilla statically, it was much more stable

[ydario]

Static linking into exe requires more memory in the lower arena since exes cannot be loaded high. And every exe will grow its size, while the dll size is shared and can be loaded high. So it there are still issues with high mem, we need to fix them since static linking is going to give us even bigger problems (in terms of memory usage).

[dmik]

Mozilla esr31 allows to link agains the system LIBVPX library so we should build it as a DLL, put it to RPM and use in Mozilla and everywhere else. Here is the port of libvpx 1.3.0 from KOMH http://hobbes.nmsu.edu/download/pub/os2/dev/mm/libvpx-v1.3.0.zip. There is not much OS/2 patches BTW — it almost builds out of the box. When doing so, we should review the KOMH patches and compare them with the Mozilla in-tree libvpx version where Mozilla-specific OS/2 patches will land. I.e. in his patch KOMH uses DosEnterCritSec to implement pthread_once functionality but this is really a dirty way (DosEnterCritSect has nothing to do with Win32's EnterCriticalSection and must not be used in regular programs at all as it may easily make an unkillable zombie that has captured some resource forever, making it unavailable to other processes until reboot). I committed a better solution to this in 0b65f0b3afeec7d65f3179482782457d13550aee.

[dryeo]

On 04/30/15 03:30 PM, Dmitriy Kuminov wrote:

Mozilla esr31 allows to link agains the system LIBVPX library so we should build it as a DLL, put it to RPM and use in Mozilla and everywhere else

Perhaps should use 1.3+ (bugfixes never actually released but in GIT) or the newly released 1.4 (Indian duck release). API is the same and minor ABI changes.

[SilvanScherrer]

NSS and NSPR are no also used as external libs. The libVPX could also be done, was we have a rpm now.

[dmik]

External LIBVPX/NSS/NSPR libs are now already used since long in Firefox. For SQLITE we have 3.7.2 and FF needs 3.9.1. So we need to update.

[dmik]

External libpng seems to work now after some recent update by @SilvanScherrer but libjpeg still doesn't due to the same problem (missing turbo extension).

[dmik]

Silvan ported libjpeg-turbo so now we can link against the system jpeg library.