This has been discussed to some extent in the netlib newsgroup, in a posting started on 7/19/99 and titled "nsNeckoUtil.cpp link problems". But there was no resolution, and so I'm entering this report so that the problem can be formally tracked. Basically there are two problems with libneckoutil_s. 1) Some other libraries use functions from neckoutil_s but do NOT link with neckoutil_s. This practice seems to be acceptable on some UNIX platforms (the ones used by the Mozilla developers, no doubt), but is not acceptable on other "UNIX-like" platforms such as Beos and OpenVMS. On these platforms the creation of these other libraries fail because of the missing neckoutil functions. I understand that on Linux this all works because the main program (viewer or apprunner) is linked with neckoutil_s and so at run time the missing functions can be found. This technique doesn't work on Beos and OpenVMS where functions have to be located at link time, not at run time. 2) libneckoutil_s is linked into several .so files. This means (at least on OpenVMS) that I end up with several copies of the contents of neckoutil in my address space. This is a waste at best and an bug at worst (imagine if neckoutil has static data). In a Mozilla world of .so files everywhere, why do we have neckoutil created as a static library and then linked into multiple .so files? Not only does this seem to be against the Mozilla tradition of modularizing everything, it just plain doesn't work on some platforms! I would like to suggest that the contents of libneckoutil_s either become a part of some other existing .so file (libnecko comes to mind) or form their own new .so file (maybe libneckoutil). OK, that's libneckoutil_s. Now what about libtimer_gtk_s? That falls into exactly the same category as libneckoutil. Do I need to submit a separate report for that one?

Putting on M9 radar.

Marking M10 and handing it over to Warren...

Colin, The reason we make neckoutil_s was to provide convenience functions that the calling dll/dso could use that would fail if the called library (in this case necko.dll) was not available (i.e. fail at runtime, rather than link time). neckoutil_s shouldn't have any static data. The function are really just wrappers for calling the service manager to get the IOService, and then calling its methods. I guess the build rules need to change for OpenVMS and BeOS -- either that or we need a completely new strategy. I'm going to assign this back to you since I don't know what to do with it, and I'm not set up to hack OpenVMS and BeOS makefiles. Warren

I'm out until 8/12. I'll take a look when I get back.

Warren, please check out my articles that Colin mentioned in n.p.m.netlib. The problem is not solveable by changing the build. It's the runtime environment that doesn't allow the kind of things that are done. The current setup simply assumes that when some random shared library references &quotNS_NewURI&quot this symbols will be magically found in a global symbol table. Well, no such thing as a global symbol table exists for BeOS or OpenVMS! It can't be fixed by a build option! I have worked around the problem under BeOS with a very ugly hack that (among other shortcomings) won't allow embedding. The new libneckoutil_s and libtimer_XXX_s haven't removed dependencies, they have HIDDEN the dependencies in implementation defined behaviour!

Warren, This is "fixable" on OpenVMS and BeOS, but its really just hacking around the real problem. In my mind the real problem is that you are creating dll/dso files with explicit references to other functions which are NOT part of any other dll/dso, and then relying on the fact that viewer and apprunner both link in the missing functions. This is not modular. Not in my mind, anyway. I understand what you are saying about these being "convenience functions", but that doesn't address the fact that this code is not modular or componentized, and anything other than Windows, Mac or UNIX is likely to have a problem with this. While I believe I can work around this problem for VMS (by explicitely including the contents of neckoutil_s into each dll/dso that uses it), the work around is ugly. It sounds like the BeOS workaround places serious restrictions on Mozilla. And the next OS to which Mozilla is ported may not have any workaround possible. So, while I'm willing to change the Makefiles so that Necko builds on OpenVMS, it really doesn't seem like the right solution. Surely this is a general "problem" with using components. Before you call a function, you must first get its address. I don't see the rest of Mozilla littered with "convenience functions" and static library files. If you really want me to hack it for a platform-specific OpenVMS solution, then assign the bug back to me. But I'm sure the BeOS folks won't be too happy, nor the next OS that stumbles onto this "convenience". Colin.

I just talked with brendan and he said I should give an update. I intend to see if we can eliminate the nsNeckoUtil glue code altogether. It will contribute a little bloat to the other dlls, but should eliminate this problem.

A few of us (Ramiro and myself for starters) have been working to update the makefiles to link neckoutil_s and timer_s into all the places that need them. I *think* that with the final updates I made this weekend, we are all set. At least on OpenVMS we are. We should check with the other "non-standard" platforms.

Spoke with warren at bug triage today. Not an M10 blocker...moving to M11.

In news://news.mozilla.org/beard-84985E.12074908101999%40news.mozilla.org, beard@netscape.com wrote: We can use NS_New* if they are inline functions in header files, that end up being short hand for progID-based calls to nsComponentManager::Create(). And, for TRUE modularity, nsComponentManager::Create shouldn't be used, instead nsIComponentManager interface references should be weakly held by each nsIModule in the system. Then, each component would have ZERO static dependencies on the other components in our system. - Patrick Why don't we just cut the static dependencies out altogether, as Patrick suggests? /be

I agree. Let's make neckoutil_s go away altogether. The thing I was waiting on before doing this was a response from dp to my question about grabbing services during GetClassObject, and whether this would prohibit unloading. He said that there are other reasons unloading is broken now anyway, so go for it.

Not essential for m11.

This has already been pushed out of M9 and M10, and now you're pushing it out of M11 into M12. Will this kind of work be allowed in M12? I thought M12 was going to be "critical fixes only". If this work is going to be done, doesn't it need doing now, while its still relatively easy to get stuff checked in. And if its not going to get done, shouldn't the bug just be closed? Just trying to be realistic....

I've got these changes sitting on a branch (no_neckoutil_branch, relative to the base tag no_neckoutil_base), but after committing them and building, the browser window doesn't come up. We just sit there in the event loop. I need to track down what the error is, and why it isn't getting reported.

I created a new branch today, no_neckoutil2_branch. This one works on windows and linux. Awaiting some mac assistance now.

I just landed this branch. The remaining work now is for someone (else) to eliminate libtimer_gtk_s. On a related note: I believe that widget/timer should be pulled out of widget and either into a top-level directory, or into xpcom. This became apparent when I merged the libs and install build phases -- timer had to be built first, but the rest of widget had to be built later. Something to consider when trying to eliminate this library. I'm going to hand this off to Pavlov. Changing summary from: "libneckoutil_s and libtimer_gtk_s are causing link problems" to "libtimer_gtk_s is causing link problems"

The timer code was fixed by ramiro a few weeks back. I think we're finally all set on this one. Thanks guys!

libneckoutil_s apparently needs to be removed from the commercial tree as well commercial tinderbox is still looking for it.

Could we please remove netwerk/util then, too? I used it for functions on my local tree and was completely irritated, that it suddenly failed.

Mass-moving non-PDT+ bugs to M13

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

so is this fixed?

Its fixed for what was libneckoutil_s Problem still exists for libtimer_s

Hmm, wait a minute. There's now a libtimer_gtk.so that gets built. But nothing ever links against it. Is this a timer service? If so, people shouldn't be calling NS_NewTimer directly, right? What's the deal here?

i have no idea.

libtimer_gtk.so does get used. Its just that we use code from a static library (that's sucked in to many different places) in order to call it.

Putting on beta1 radar.

Not obvious to pdt what the actuall beta blocker is, can you please use "small words" for the PDT please. :-)

Platform: Beos and OpenVMS (i.e. not tier 1) Colin, is this still an issue for you though?

I think the way it works now is that the real timer code is in the sharable libtimer_gtk.so, but in all the places that its invoked from, the static code libtimer_s is used to invoke it. So its kind of fixed, but not totally. We still have a static library linked into multiple .so files. Only now its not the real code, its "helper" code. As to whether this is "an issue" for me? No. OpenVMS doesn't mind if you waste space by linking the same code into multiple sharable images. But is it "right"? That's a tough one. It still doesn't feel right to be linking the same code statically into multiple .so files.

Sounds like we should close this, unless Pav is a perfectionist.

Putting on PDT- radar for beta1.

closing

marking verified

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

This isn't fixed -- we're still statically linking MOZ_TIMER_LIB (libtimer_s) all over the place.

I was going to fix this. My bug.

Actually reassign it to me.

Ok, I have a plan to fix this. It looks like an XP problem that affects the mac and windows, too. Can anyone confirm or deny this?

Moving out...

spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF bugs

Please ignore the spam. Changing address.

bustage from my reassign

taking from blizzard

libtimer_*_s.a is no more. next step is to remove NS_NewTimer completly. I have filed bug 39523 for tracking of removing NS_NewTimer

verified