Closed Bug 11159 Opened 25 years ago Closed 24 years ago

libtimer_gtk_s is causing link problems

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
All
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: colin, Assigned: pavlov)

References

Details

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?
Target Milestone: M9
Putting on M9 radar.
Assignee: gagan → warren
Target Milestone: M9 → M10
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
Assignee: warren → colin
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!
Assignee: colin → warren
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M11 → M12
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....
Blocks: 17907
Blocks: 18471
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.
Blocks: 18951
I created a new branch today, no_neckoutil2_branch. This one works on windows
and linux. Awaiting some mac assistance now.
Assignee: warren → pavlov
Status: ASSIGNED → NEW
Summary: libneckoutil_s and libtimer_gtk_s are causing link problems → libtimer_gtk_s is causing link problems
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?
Target Milestone: M13 → M14
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.
Keywords: beta1
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.
Whiteboard: [PDT-]
closing
Status: NEW → RESOLVED
Closed: 25 years ago
Keywords: beta1
Resolution: --- → FIXED
marking verified
Status: RESOLVED → 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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I was going to fix this.  My bug.
Status: REOPENED → ASSIGNED
Actually reassign it to me.
Assignee: pavlov → blizzard
Status: ASSIGNED → NEW
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...
Target Milestone: M14 → M16
Status: NEW → ASSIGNED
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF 
bugs
QA Contact: paulmac → tever
Please ignore the spam.  Changing address.
Assignee: blizzard → blizzard
Status: ASSIGNED → NEW
bustage from my reassign
Status: NEW → ASSIGNED
taking from blizzard
Assignee: blizzard → pavlov
Status: ASSIGNED → NEW
Whiteboard: [PDT-]
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
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
No longer blocks: 17907
No longer blocks: 18471
No longer blocks: 18951
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.