208345 - MSVC++ .net 2003: libIDL binary crashes during build

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Hixie (not reading bugmail)]

The libIDL library used for VC7-based builds is not binary compatible with the
MSVC++ .net 2003 compiler, so it crashes.

I have created (using cls' patches in bug 123743) new binaries that are compiled
with the MSVC++ Standard .net 2003 compiler. They are therefore unoptimised
binaries (the MSVC++ Standard compiler does not support optimisations).

What do drivers/staff want to do with these binaries? Having to recompile these
libraries and provide binaries every time Microsoft release a new compiler is
not really a viable model.

See also:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=ba9isr%24cec2%40ripley.netscape.com

Comment 1

[Hixie (not reading bugmail)]

Attachment: libIDL, glib, and pthread binaries compiled by MSVC++ Standard .net 2003

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is distributing binaries of things with a GPL-ish license legal according to the
license for that version of MSVC?

Comment 3

[Hixie (not reading bugmail)]

Yes -- it's not the student version, it's the most expensive version that
doesn't require me to take out a mortgage. As far as I can tell the license
doesn't mention any restrictions on compiled code, and doesn't make any mention
of free software licenses anywhere.

Comment 4

[Ali Ebrahim]

Ian, could you make available as an attachment the patched sources files for
pthreads, glib and libidl?

Comment 5

[Hixie (not reading bugmail)]

I used the patches in bug 123743.

Comment 6

[Ali Ebrahim]

What is left to be done before this bug can be considered resolved? Ian Hixie's
attachment has been tested by many people and has been verified to work.

Does the Mozilla.org Win32 build page (http://www.mozilla.org/build/win32.html)
need to be updated with information about these libIDL/glib binaries? Or do we
open another bug for that?

Comment 7

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 8

[Daniel (Leaf) Nunes]

I will try and update the win32 docs this week, and move the built binaries to
ftp .mozilla.org.

Since the only windows compiler i have access to right now is 2003 C++.NET
standard, i'm a little disconcerted that it doesn't support optimizations. *sigh*

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

How long does building the binaries in attachment 1 [details] [diff] [review] take?  Could we put a forked
copy of these libraries in other-licenses/ and make it part of the build process
on Windows?

Comment 10

[Ali Ebrahim]

(In reply to comment #9)
> How long does building the binaries in attachment 1 [details] [diff] [review] take?

Not more than 2 minutes on P4 system. It'd be great to get rid of these 
dependencies and have them as part of the build process.

Comment 11

[Nick Bebout]

Leaf:

Would you like me to update the build/win32.html page?

Comment 12

[timeless]

*** Bug 234600 has been marked as a duplicate of this bug. ***

Comment 13

[Henry Wasserman]

I have the latest MSVC++ .net super expensive compiler, if you show me how to 
build this thing I'll do it.  [e-mail]

Comment 14

[cls]

*** Bug 236163 has been marked as a duplicate of this bug. ***

Comment 15

[cls]

(In reply to comment #9)
> How long does building the binaries in attachment 1 [details] [diff] [review] take?  Could we put a forked
> copy of these libraries in other-licenses/ and make it part of the build process
> on Windows?

Ugh. Didn't we just get out of that situation with the hacked up classic mac
versions of glib & libIDL (bug 98811)?  The moment you add them, people are
going to start wondering why we have an external requirement for these libs on
other platforms when they live in our tree.  Unlike the other libs that live
under other-licenses/, glib & libidl are only used during the build and nothing
shipped depends upon them (unless you count xpidl.exe in the gecko-sdk).  And
why do we want to constantly recompile these libs which will almost never change
when someone can do it once and put it on the ftp site?  Let's keep the external
requirements external.

Comment 16

[Ali Ebrahim]

(In reply to comment #15)
> when someone can do it once and put it on the ftp site?  Let's keep the external
> requirements external.

If we're going to do this, can mozilla.org at least host fully patched source
files that are nmake compatible and do the right thing in terms of directory
structure so that people who need to compile the libraries just have to download
and compile quickly.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If we're not going to build them, it would be nice if moztools.zip or whatever
it is these days had the copies for all compilers that we support and the tools
automatically picked the right one based on _MSC_VER.  How hard is that to do?

Comment 18

[cls]

aebrahim: I'd really like to not have a completely forked set of sources hosted
by m.o since we are not taking over development of those packages (same reason I
don't want them in the tree).  However, the patches should be make more easily
accessible than the bug they're currently buried in if we're going to start
distributing binaries.

dbaron: Finding someone with the time and access to all of the compilers (or at
least the prebuilt libs) to do it.  There have been a couple of requests for an
updated wintools.zip anyway.

Comment 19

[cls]

Actually, we should skip the combined wintools.zip all together.  Just provide
nsinstall and individual glib/libIDL libs & headers separately.

Comment 20

[David Bradley]

*** Bug 239406 has been marked as a duplicate of this bug. ***

Comment 21

[Doug Turner (:dougt)]

leaf, can you please post this to ftp.mozilla.org and update the build page?  I
had to dig through newsgroup postings to find out about this bug.

Comment 22

[cls]

dougt, since you more than likely have the pro version of VC .NET, can you
compile  the binaries using the patches from bug 123743 and attach the optimized
versions to this bug?  We went through this same waiting for someone to
contribute optimized versions bit with the VC7 bins.

Comment 23

[Robert Parenton]

I have VS.NET 2003 Pro, and I'll be happy to build and attach optimized
versions, if someone can point me to the instructions of how to build them.

Comment 24

[Robert Parenton]

Also, what are the desired optimizations?  I would guess the following:

-G6 -O1

Is that correct?

Comment 25

[Ali Ebrahim]

(In reply to comment #24)
> Also, what are the desired optimizations?  I would guess the following:
> 
> -G6 -O1
> 
> Is that correct?

I would imagine that "-O2 -G7" would be better, or possibly even "-Ox -G7".

Comment 26

[cls]

The defaults listed in the msvc makefiles should be fine.  We don't need to
trigger any potential bugs by bumping that optimization level to something that
hasn't been tested with these sources.  Also, I don't recall if -G6/-G7 is a
scheduling or architecture switch and we definitely don't want to make these
libraries only work on P3 or P4 if we're going to distribute them for all win32
builders to use.

Comment 27

[Robert Parenton]

Attachment: glib, libIDL, & pthread Binaries Compiled by MCVC .NET 2003 Professional (Optimized)

Optimized versions of the binaries compiled with MSVC .NET 2003 Professional
according to the instructions in comment #26.

Comment 28

[Robert Parenton]

Attachment: glib, libIDL, & pthread Binaries Compiled by MCVC .NET 2003 Professional (Optimized) w/ Readme

Same as before but with a readme this time

Comment 29

[Daniel (Leaf) Nunes]

testing.

Comment 30

[Jon Henry]

I successfully built Firefox last night using MSVC .NET 2003 pro on Win XP with
these files and so far haven't seen any adverse affects.

Comment 31

[Ali Ebrahim]

(In reply to comment #26)
> hasn't been tested with these sources.  Also, I don't recall if -G6/-G7 is a
> scheduling or architecture switch and we definitely don't want to make these
> libraries only work on P3 or P4 if we're going to distribute them for all win32
> builders to use.

FYI, -G6/-G7 are scheduling switches, and don't affect the code's ability to run
on older CPUs (they only affect the speed at which they run). The architecture
switches that limit binary compatibility with older systems are
-arch:SSE/-arch:SSE2.

Comment 32

[Daniel (Leaf) Nunes]

I've re-bundled the .NET compiled binaries into the wintools library collection:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools-dotnet.zip

Robert, do you have any zip files that look like what's in:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32
?

Comment 33

[Robert Parenton]

Attachment: vc71-glib-1.2.10-bin Package Leaf Requested

Comment 34

[Robert Parenton]

Attachment: vc71-pthreads-snap-2001-07-03-bin Package Leaf Requested

Comment 35

[Robert Parenton]

Attachment: vc71-libIDL-0.6.8-bin Package Leaf Requested

Comment 36

[Robert Parenton]

Leaf, are these what you wanted?

Comment 37

[Daniel (Leaf) Nunes]

(In reply to comment #36)
> Leaf, are these what you wanted?

Yes, exactly. I'll get these posted in the
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32 directory presently.

Comment 38

[cls]

I've uploaded the vc71 glib & libIDL packages with a few small changes:
* changed the toplevel dir from MOZ_TOOLS.NET to vc71 to be consistent with the
vc7 packages
* renamed readme.txt to README.<pkg> to avoid overwriting the file when both
packages are installed
* ran dos2unix on the headers

The build page still needs to be updated.