Static linking causing unresolved externals
c051n3
friends) while compiling jseng-1.5 with JS_THREADSAFE defined is giving
me the following errors (I've removed duplicates):
jsapi.obj : error LNK2001: unresolved external symbol __imp__PR_NewCondVar
jsapi.obj : error LNK2001: unresolved external symbol __imp__PR_NewLock
jsapi.obj : error LNK2001: unresolved external symbol
__imp__PR_DestroyCondVar
jsstr.obj : error LNK2001: unresolved external symbol __imp__PR_Unlock
jsobj.obj : error LNK2001: unresolved external symbol __imp__PR_WaitCondVar
jsstr.obj : error LNK2001: unresolved external symbol __imp__PR_Lock
jsapi.obj : error LNK2001: unresolved external symbol
__imp__PR_NotifyCondVar
jsregexp.obj : error LNK2001: unresolved external symbol
__imp__PR_AtomicIncrement
jsscript.obj : error LNK2001: unresolved external symbol
__imp__PR_AtomicDecrement
jslock.obj : error LNK2001: unresolved external symbol
__imp__PR_GetCurrentThread
However, when building jseng using the DLL .lib versions everything is
ok and compiles cleanly with no errors.
Were these functions forgotten in the static build?
Is this a jseng wrapper type thing?
Did I miss something automagic somewhere along the way?
Thank you for your time.
c051n3
> c051n3 wrote:
>> Using the nspr-4.4.1 prebuilt static libraries (e.g. libnspr4_s.lib
>> and friends) while compiling jseng-1.5 with JS_THREADSAFE defined is
>> giving me the following errors (I've removed duplicates):
>
> We don't support linking with NSPR's static libraries.
> Our binary distributions only contain DLLs.
>
> The reason we still generate the static libraries when
> we build NSPR from source code is that one of the NSS
> crypto libraries (nssckbi.dll) uses the NSPR static
> libraries. That bug will be fixed in the upcoming
> NSS 3.11 release.
>
> If you really need to use NSPR static libraries, you
> can eliminate the unresolved externals you reported
> by compiling all of your files with the -D_NSPR_BUILD_
> compiler flag. Again, you should only do this if you
> must use NSPR static libraries. Please note the following
> two problems:
> 1. Threads created outside NSPR can call NSPR functions
> with no problem, but their PRThread structures will be
> leaked when they terminate, because we free their
> PRThread structures in the DllMain function of
> libnspr4.dll/nspr4.dll. This is not an issue if all
> the threads that call NSPR functions are created by
> NSPR (PR_CreateThread).
> 2. All the NSPR public functions will be exported from
> your executable or DLL because they are defined with the
> __declspec(dllexport) keyword (the value of the PR_IMPLEMENT
> macro).
>
> Wan-Teh
Thank you for this info, Wan-Teh. Basically, what I'm trying to
accomplish is to combine my project's code with NSPR and JS to create
just one distributable shared object (.so/.dll).
Since my project does indeed require threads I will be using
PR_CreateThread and putting the NSPR and JS init code together with my
code in the dllmain section just to ensure things init/finish properly
since I expect extremely high usage of threads.
Thanks again!
Wan-Teh Chang
>
> Thank you for this info, Wan-Teh. Basically, what I'm trying to
> accomplish is to combine my project's code with NSPR and JS to create
> just one distributable shared object (.so/.dll).
After I wrote my last reply, I thought of another problem:
multiple copies of NSPR in a process.
Your .so/.dll will contain a copy of NSPR if you link with
NSPR static libraries.
If the executable program or some other .so/.dll also uses
NSPR (the .so/.dll), the process will end up with two copies
of NSPR. In the past, this caused problems on at least Windows
and AIX.
Wan-Teh
c051n3
Fortunately, the project I'm working on will be using "my" NSPR'd dll.
However, I wanted to generalize its functionality such that *any*
application could link to it. Thus, from your statement above I
conclude that I will encounter issues with applications already
embedding nspr calls that will also link to my dll.
Since Windows is most definitely a target platform for me, as is Linux,
I assume that your recommendation is to just simply use the prebuilt
NSPR binaries and require the distribution of 3 dlls - nspr, js, and my
dll - in order to support the functionality that my dll will provide?
As an example, use of that functionality will be available from a web
server module loaded by either Microsoft's IIS ISAPI or Apache's mod_so.
Do you happen to know of any issues that might also arise from the
interaction of NSPR with ISAPI or Apache's APR for Apache httpd modules?
I'm just hoping I don't need to develop and distribute yet another dll
to provide isolation from those environments.
Thank you again for your time!
Wan-Teh Chang
>
> Fortunately, the project I'm working on will be using "my" NSPR'd dll.
> However, I wanted to generalize its functionality such that *any*
> application could link to it. Thus, from your statement above I
> conclude that I will encounter issues with applications already
> embedding nspr calls that will also link to my dll.
Yes. It may still work under some circumstances, but
it's very hard to ensure that your NSPR'd dll will only
be used in those circumstances. So it is best to link
with NSPR shared libraries/DLLs so that multiple copies
of NSPR aren't an issue at all.
> Since Windows is most definitely a target platform for me, as is Linux,
> I assume that your recommendation is to just simply use the prebuilt
> NSPR binaries and require the distribution of 3 dlls - nspr, js, and my
> dll - in order to support the functionality that my dll will provide?
Yes, that's my recommendation. On Windows, I also recommend
that you use js and nspr as "private DLLs" and not install
them in the C:\WINDOWS\System32 directory. Private DLLs are
not shared with other applications and are usually installed
in the directory where the application executable resides.
Your installer should also check for an existing js or nspr
dll in that directory and only overwrite it if yours is newer.
> As an example, use of that functionality will be available from a web
> server module loaded by either Microsoft's IIS ISAPI or Apache's mod_so.
> Do you happen to know of any issues that might also arise from the
> interaction of NSPR with ISAPI or Apache's APR for Apache httpd modules?
> I'm just hoping I don't need to develop and distribute yet another dll
> to provide isolation from those environments.
NSPR has been used successfully in ISAPI. I don't know about
Apache's mod_so.
When used in ISAPI, the only issue is that you can't load and
unload repeatedly. This is because PR_Cleanup isn't completely
implemented, so every time you call PR_Cleanup you have some
resource/memory leaks. In particular, in the "WINNT" version
you also leak an NSPR internal thread, which will crash. So
you need to do something to ensure that IIS loads the NSPR dll
and never unloads it.
It is possible to fix PR_Cleanup so that it cleanup shuts down
the internal threads and releases all the resources and memory.
But I don't have time to do that.
Wan-Teh