This new module needs a short dll name. The attached patch to mozilla/browser/components/dirprovider/Makefile.in dubs it "brwsrdir".
I learned in Bug 286494 that Windows uses the same variable so one needs to do something like this ifneq ($(OS_ARCH),WINNT) SHORT_LIBNAME = brwsrdir endif
yeah, definitely need the WINNT stuff.
Created attachment 186893 [details] [diff] [review] revised patch
Attachment #186774 - Attachment is obsolete: true
Why does this need a shortname? Aren't the OS/2 release builds static builds?
I think Mike's release builds were non-static, but even if they were static we should still keep non-static builds working on OS/2.
The are several things I don't understand here: a while back I thought mkaply told me not to worry about long names any more: we use longnames (such as extensions-startup.manifest) in the profile. Furthermore, I don't think you (or I) should be worrying about non-static configurations: I have been adding little dynamic components willy-nilly trusting that in release configurations they will be merged into the static binary, and your perf is going to suck if you are releasing dynamic builds.
Long filenames are not a problem on OS/2, _except_ for DLLs. If DLLs have more than 8.3 chars they cannot be loaded and Firefox probably won't run, if the DLL is dynamically linked at compile time. I agree that static builds are the way to go for releases, even though they don't seem to make much of a difference regarding performance. (I don't have numbers to back this up at the moment, though.) But for debugging etc. we need to keep the SHORT_LIBNAME stuff just to keep Firefox running.
Also, debug builds cannot be static on OS/2, so in order to debug, we have to maintain the short names.
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.