193007 - Missing symbols for options file

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Colin Blake]

It looks like when I revised the linker options file (bug 185034), a few symbols
were missed. And one of them (PR_CreateThread) is used by Java in OJI, so now
Java doesn't work. 

The full list of missing "PR_" symbols is:

  PR_GetLibraryFilePathname
  PR_FPrintZoneStats
  PR_SetError
  PR_CallOnceWithArg
  PR_CreateThread

Wan-Teh, can you tell me if these are all meant to be visible?

Comment 1

[Wan-Teh Chang]

Export these:
  PR_GetLibraryFilePathname
  PR_SetError
  PR_CallOnceWithArg
  PR_CreateThread

Comment 2

[Colin Blake]

Attachment: Add missing symbols

Here's the patch to provide the missing symbols. Once I've heard back from our
Java group that this is the solution they want to go with, I'll ask for a
review.

Comment 3

[Colin Blake]

Wan-Teh, this is turning out to be a real mess. There are several partial
solutions to the situation I am now in, but each of these partial solutions
means that some combination of Mozilla version and Java version won't work
together. The one REAL solution is to insert a bunch of dummy entries in the
transfer vector to pad things out so that PR_CreateThread ends up where it was
in the Mozilla 1.1 release (this is what Java 1.4-0 was linked against). But
each dummy entry would require a stub in NSPR in order to generate a valid
symbol. We already have 3 stubs in pr/src/md/unix/openvms.c to paper over
previous symbol vector hiccups. How would you feel about another 100 or so (not
sure of the exact number just yet)?

Comment 4

[Colin Blake]

Its only 51 additional stubs I need, Wan-Teh. This solution is really the only
way to keeping Mozilla and Java happilly married. Are you in?

Comment 5

[Wan-Teh Chang]

Adding these stubs for binary compatibility on OpenVMS
is not a problem.

Comment 6

[Colin Blake]

Attachment: New patch

Add new/missing symbols to symbol vector, and insert enough stubs so that
PR_CreateThread is located in its Mozilla 1.1 position (this makes Java work).

Comment 7

[Wan-Teh Chang]

Note that
  PR_SetError
  PR_CreateThread
are pre-existing functions (they have been in NSPR
since day one), and
  PR_GetLibraryFilePathname
  PR_CallOnceWithArg
were new functions added last month.

I think we need to make sure that the two new functions
not occupy the positions used by other functions before
in the symbol vector, right?

Comment 8

[Colin Blake]

We only care about the public symbols. And since Java is the only other app
linking against NSPR and it was only missing PR_CreateThread, that's the only
symbol we need to worry about. 

Any other apps which come along and link against NSPR will use at least Mozilla
1.3's NSPR, and will be binary upward compatible with any release after 1.3.

Comment 9

[Wan-Teh Chang]

I'll leave it to you because you know the history
best.

It's cheap to add these stubs, so we should not
try to save two stubs.

Comment 10

[Colin Blake]

Comment on attachment 114445 [details] [diff] [review]
New patch

Java is working with this patch. This is what I'd like checking in.

Comment 11

[Wan-Teh Chang]

Comment on attachment 114445 [details] [diff] [review]
New patch

r=wtc.

Do you really need to bump the version from 2,3 to 2,4?
2,3 hasn't been used in any (final) release, right?

Comment 12

[Colin Blake]

It doesn't matter how much the ident bumps. I used 2,3 internally so I prefer to
go to 2,4.

Comment 13

[Wan-Teh Chang]

Patch checked into the NSPR TIP (NSPR 4.3) and the
NSPRPUB_PRE_4_2_CLIENT_BRANCH (mozilla 1.4alpha).