The control needs dynamic XPCOM components so don't bother building in the statically linked build mode when they don't exist.
Is another solution to make Firebird use dynamic XPCOM components instead of static? There are a lot of products that will use the mozilla platform in the future...and now Ngu (Front Page replacement), Evolution, etc.. Does this mean that firebird is taking up extra space and memory by not sharing? There are ways to deal with dynamically loaded libraries... prelinking and such. Multi threading (waiting for something to come from disk or network, do something else) I guess I don't know what XPCOM is... even though I've read lots of mozilla developer docs... yay for acronyms!
Yes, Firebird takes up extra space by not sharing with other apps but probably benefits (a great deal) by having a much smaller number of things to load up and resolve at runtime, easier installation (unzip and run) and also a smaller disk and memory footprint. I suppose it could be built in either mode, but you would have to ask the project leads rationale is for it. Probably it's done for the reasons I said above.
*** Bug 209562 has been marked as a duplicate of this bug. ***
The ActiveX embedding API was removed in bug 662023 and friends, making this INVALID. [Filter bugspam on activexinvalid]
Assignee: adamlock → nobody
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Component: Embedding: ActiveX Wrapper → Embedding: ActiveX Wrapper
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.