Build non-static version of IPC component
mimec...@gmail.com
Brunschwig, src code here: http://www.mozdev.org/source/browse/enigmail/src/ipc/
) building for a while now but to no avail.
The thing is the code works well with static builds of Firefox or
Thunderbird but for non-static builds I can't get it to build. I keep
getting:
link -NOLOGO -DLL -OUT:ipc.dll -PDB:ipc.pdb -SUBSYSTEM:WINDOWS
nsIPCModule.obj ./module.res -NXCOMPAT -SAFESEH -
IMPLIB:fake.lib ../src/ipc_s.lib ../../../dist/lib/
xpcom.lib ../../../dist/lib/xul.lib ../../../dist/lib/
xpcomglue_s.lib ../../../dist/lib/xpcom_compat.lib ../../../dist/lib/
nspr4.lib ../../../dist/lib/plc4.lib ../../../dist/lib/plds4.lib
kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib
advapi32.lib
Creating library fake.lib and object fake.exp
ipc_s.lib(nsIPCBuffer.obj) : error LNK2001: unresolved external symbol
"public: void __fastcall nsACString_internal::Assign(class
nsACString_internal const &)" (?
Assign@nsACString_internal@@QAIXABV1@@Z)
ipc_s.lib(nsIPCService.obj) : error LNK2019: unresolved external
symbol "public: void __fastcall nsACString_internal::Assign(class
nsACString_internal const &)" (?
Assign@nsACString_internal@@QAIXABV1@@Z) referenced in function
"public: void __thiscall nsACString_internal::Append(char const
*,unsigned int)" (?Append@nsACString_internal@@QAEXPBDI@Z)
ipc_s.lib(nsPipeTransport.obj) : error LNK2001: unresolved external
symbol "public: void __fastcall nsACString_internal::Assign(class
nsACString_internal const &)" (?
Assign@nsACString_internal@@QAIXABV1@@Z)
...and it goes on...
By the way, there is a bug open right now to add this extension to the
mozilla codebase but it's 7(!) years old and in the meantime I'd like
to get it working. See https://bugzilla.mozilla.org/show_bug.cgi?id=68702
Also, I obviously contacted Patrick (the maintainer) first but he says
it's probably a complicated fix and he's pretty busy so...
Thoughts, anybody?
Mime Cuvalo
Barry
switch from the Mozilla internal API to the frozen API. See the page
http://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_to_Frozen_Linkage
and the pages it links to. In particular see the comments on libraries
that need to be linked when you are using the frozen linkage (http://
developer.mozilla.org/en/docs/
XPCOM_Glue#Frozen_linkage:_dependent_glue_.28dependent_on_xpcom.dll.
29). In this case, since the IPC stuff *should* be part of XulRunner,
I think you might be justified in making the IPC use internal linkage.
The key to doing this seems to be adding "LIBXUL_LIBRARY = 1" to the
right makefile.
--Barry
> to get it working. Seehttps://bugzilla.mozilla.org/show_bug.cgi?id=68702
Mime
not a .lib (I'll be packaging it with an extension). Any other
thoughts?
Mime
On Dec 4, 12:13 pm, Barry <barry.mackic...@mackichan.com> wrote:
> I've seen thee messages before, and they seem to be related with the
> switch from the Mozilla internal API to the frozen API. See the pagehttp://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_...
Benjamin Smedberg
> 29). In this case, since the IPC stuff *should* be part of XulRunner,
> I think you might be justified in making the IPC use internal linkage.
> The key to doing this seems to be adding "LIBXUL_LIBRARY = 1" to the
The IPC stuff is not part of XULRunner (or Firefox) and there are no plans
to include it at this time. Assuming that you want to ship it as part of an
extension, you will need to make it use frozen linkage.
>> link -NOLOGO -DLL -OUT:ipc.dll -PDB:ipc.pdb -SUBSYSTEM:WINDOWS
>> nsIPCModule.obj ./module.res -NXCOMPAT -SAFESEH -
>> IMPLIB:fake.lib ../src/ipc_s.lib ../../../dist/lib/
>> xpcom.lib ../../../dist/lib/xul.lib ../../../dist/lib/
>> xpcomglue_s.lib ../../../dist/lib/xpcom_compat.lib ../../../dist/lib/
>> nspr4.lib ../../../dist/lib/plc4.lib ../../../dist/lib/plds4.lib
>> kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib
>> advapi32.lib
>> Creating library fake.lib and object fake.exp
>> ipc_s.lib(nsIPCBuffer.obj) : error LNK2001: unresolved external symbol
>> "public: void __fastcall nsACString_internal::Assign(class
>> nsACString_internal const &)" (?
Your makefile defines MOZILLA_INTERNAL_API, which causes the code to try to
link with symbols that are not available outside of libxul.
--BDS
Justin Wood (Callek)
> Barry wrote:
>
>> 29). In this case, since the IPC stuff *should* be part of XulRunner,
>> I think you might be justified in making the IPC use internal linkage.
>> The key to doing this seems to be adding "LIBXUL_LIBRARY = 1" to the
>
> The IPC stuff is not part of XULRunner (or Firefox) and there are no plans
> to include it at this time. Assuming that you want to ship it as part of an
> extension, you will need to make it use frozen linkage.
>
Forgive me ben, but I have (frequently for over a year) been hearing
that the IPC stuff [what this thread is about] would be great to include
in the "basic" Gecko//XULRunner along-side the other (basic) IPC
implementation we have. Provided someone does the work to get it,
reviewed, working, and in. And as long as someone agrees to "own" it.
If that changed, I'd love to hear a why?
~Justin Wood (Callek)
Mime
> link with symbols that are not available outside of libxul.
Well, so I got rid of MOZILLA_INTERNAL_API and started converting the
code using the guidelines listed here at
http://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_to_Frozen_Linkage
but I run into errors.
Again, this isn't my code - and I don't do very much C++ coding so I
kind of need some hand-holding on this :)
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1133) : error
C2664: 'PRInt32 nsACString::Find(const nsACString::self_type
&,PRUint32,nsACString::ComparatorFunc) const' : cannot convert
parameter 1 from 'const char *' to 'const nsACString::self_type &'
Reason: cannot convert from 'const char *' to 'const
nsACString::self_type'
No constructor could take the source type, or constructor
overload resolution was ambiguous
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1167) : error
C2039: 'get' : is not a member of 'nsDependentCSubstring_external'
../../../dist/include/xpcom\nsStringAPI.h(1128) : see
declaration of 'nsDependentCSubstring_external'
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1212) : error
C2039: 'ReplaceSubstring' : is not a member of 'nsCString_external'
../../../dist/include/xpcom\nsStringAPI.h(729) : see
declaration of 'nsCString_external'
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1213) : error
C2039: 'ReplaceSubstring' : is not a member of 'nsCString_external'
../../../dist/include/xpcom\nsStringAPI.h(729) : see
declaration of 'nsCString_external'
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1243) : error
C2039: 'ReplaceSubstring' : is not a member of 'nsCString_external'
../../../dist/include/xpcom\nsStringAPI.h(729) : see
declaration of 'nsCString_external'
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1244) : error
C2039: 'ReplaceSubstring' : is not a member of 'nsCString_external'
../../../dist/include/xpcom\nsStringAPI.h(729) : see
declaration of 'nsCString_external'
c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1269) : error
C2039: 'get' : is not a member of 'nsDependentCSubstring_external'
../../../dist/include/xpcom\nsStringAPI.h(1128) : see
declaration of 'nsDependentCSubstring_external'
make[2]: *** [nsPipeTransport.obj] Error 2
make[2]: Leaving directory `/c/moz2/mozilla/obj-i686-pc-mingw32/
extensions/ipc/src'
make[1]: *** [libs] Error 2
make[1]: Leaving directory `/c/moz2/mozilla/obj-i686-pc-mingw32/
extensions/ipc'
make: *** [all] Error 2
For example, for one of those errors ('get' : is not a member, etc.)
the code is doing:
const nsDependentCSubstring outStr = StringHead(mExecBuf,
returnCount);
mExecBuf.Cut(0,returnCount);
*_retval = PL_strdup(outStr.get()); // something's wrong here
Mook
>> Your makefile defines MOZILLA_INTERNAL_API, which causes the code to try to
>> link with symbols that are not available outside of libxul.
>
> Well, so I got rid of MOZILLA_INTERNAL_API and started converting the
> code using the guidelines listed here at
> http://developer.mozilla.org/en/docs/Migrating_from_Internal_Linkage_to_Frozen_Linkage
> but I run into errors.
>
> Again, this isn't my code - and I don't do very much C++ coding so I
> kind of need some hand-holding on this :)
>
> c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1133) : error
> C2664: 'PRInt32 nsACString::Find(const nsACString::self_type
> &,PRUint32,nsACString::ComparatorFunc) const' : cannot convert
> parameter 1 from 'const char *' to 'const nsACString::self_type &'
> Reason: cannot convert from 'const char *' to 'const
> nsACString::self_type'
> No constructor could take the source type, or constructor
> overload resolution was ambiguous
NS_COM PRInt32 Find( const char* aString, PRBool aIgnoreCase=PR_FALSE,
PRInt32 aOffset=0, PRInt32 aCount=-1 ) const;
external string uses
NS_HIDDEN_(PRInt32) Find(const char_type *aStr, PRUint32 aLen,
ComparatorFunc c = DefaultComparator) const;
Yes, the args are completely different. Length moved, there's no offset
anymore (use a substring), and it now takes CaseInsensitiveCompare
instead of number. Probably should check all callers of find to make
sure it's not accidentally compiling. :(
> c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1167) : error
> C2039: 'get' : is not a member of 'nsDependentCSubstring_external'
> ../../../dist/include/xpcom\nsStringAPI.h(1128) : see
> declaration of 'nsDependentCSubstring_external'
(See below)
> c:/moz2/mozilla/extensions/ipc/src/nsPipeTransport.cpp(1212) : error
> C2039: 'ReplaceSubstring' : is not a member of 'nsCString_external'
> ../../../dist/include/xpcom\nsStringAPI.h(729) : see
> declaration of 'nsCString_external'
You'll need to rewrite this using Find + Replace (and I don't mean an
editor). Or a helper function, since you have multiple occurrences of this.
>
> For example, for one of those errors ('get' : is not a member, etc.)
> the code is doing:
> const nsDependentCSubstring outStr = StringHead(mExecBuf,
> returnCount);
> mExecBuf.Cut(0,returnCount);
> *_retval = PL_strdup(outStr.get()); // something's wrong here
outStr.BeginReading()?
Note that PL_strdup is quite possibly wrong (incorrect allocator);
unless you're sending it to something non-XPCOM (e.g. NSPR), you
probably want ToNewCString(outStr). PL_strdup should be matched with
PL_strfree which is quite likely not the case :(
Mentioned in passing in
http://developer.mozilla.org/en/docs/Choosing_the_right_memory_allocator#Allocating_strings_in_XPCOM_code
HTH.
--
Mook
mook dot moz plus stuff at gmail
still scarred from xpfe search thingy
Enrico Weigelt
Hi folks,
> Forgive me ben, but I have (frequently for over a year) been hearing
> that the IPC stuff [what this thread is about] would be great to include
> in the "basic" Gecko//XULRunner along-side the other (basic) IPC
> implementation we have. Provided someone does the work to get it,
> reviewed, working, and in. And as long as someone agrees to "own" it.
actually, I never really understood, what this IPC component
is really for ;-O
You want to move some stuff outside the main process ?
Fine. Great thing, and should really be done with many parts of
Mozilla (eg. plugins, profile storage, message storage/access, etc).
BUT: why don't you just use 9P for that ?
It's an wonderful - platform and network agnostic - IPC mechanism
with filesystem semantics.
* http://swtch.com/plan9port/man/man9/intro.html
* http://nekrad.wordpress.com/2007/09/08/libmixp-362-finished/
* http://oss-qm.metux.de/index.php/9forge
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
Benjamin Smedberg
>> The IPC stuff is not part of XULRunner (or Firefox) and there are no
>> plans
>> to include it at this time. Assuming that you want to ship it as part
>> of an
>> extension, you will need to make it use frozen linkage.
>>
>
> Forgive me ben, but I have (frequently for over a year) been hearing
> that the IPC stuff [what this thread is about] would be great to include
> in the "basic" Gecko//XULRunner along-side the other (basic) IPC
> implementation we have. Provided someone does the work to get it,
> reviewed, working, and in. And as long as someone agrees to "own" it.
>
> If that changed, I'd love to hear a why?
We're well past feature-freeze for gecko 1.9, and there's not a clear
use-case for it within the core platform. Please note that the code in
mozilla/ipc is not the same as bug 68702 (protozilla scriptable access to
subprocess stdin/stdout/stderr streams)... it was designed for profile-sharing.
--BDS
Justin Wood (Callek)
> Justin Wood (Callek) wrote:
>
>>> The IPC stuff is not part of XULRunner (or Firefox) and there are no
>>> plans
>>> to include it at this time. Assuming that you want to ship it as part
>>> of an
>>> extension, you will need to make it use frozen linkage.
>>>
>> Forgive me ben, but I have (frequently for over a year) been hearing
>> that the IPC stuff [what this thread is about] would be great to include
>> in the "basic" Gecko//XULRunner along-side the other (basic) IPC
>> implementation we have. Provided someone does the work to get it,
>> reviewed, working, and in. And as long as someone agrees to "own" it.
>>
>> If that changed, I'd love to hear a why?
>
> We're well past feature-freeze for gecko 1.9
I don't think anyone was saying that *now* it should be part of Gecko
1.9 (though the reviews have been awfully slow in my eyes, so it is no
fault of the guys working on it)
> and there's not a clear
> use-case for it within the core platform.
Theres no use-case for it in "Firefox", but I'd say Enigmail is a great
use-case for it in the platform. How about cases where an XULRunner app
would want to run "make check" on a build, and report the results in a
human readable way, via what this IPC provides, etc...
Please note that the code in
> mozilla/ipc is not the same as bug 68702
Never said it was...
> it was designed for profile-sharing.
>
Yes, and that was never made a reality, as support for Mozilla Suite
dropped before that was "finished" (or so I've been told in my time here).
~Justin Wood (Callek)
Benjamin Smedberg
> Theres no use-case for it in "Firefox", but I'd say Enigmail is a great
> use-case for it in the platform. How about cases where an XULRunner app
> would want to run "make check" on a build, and report the results in a
> human readable way, via what this IPC provides, etc...
Just because "X could use it" doesn't mean we should ship it in the
platform... it's pretty clear that IPC mechanisms can be made as extensions,
and so we should bias towards that solution unless there's a compelling
reason why it should be shared. Those reasons might be:
* features we want to expose consistently to web content
* features that cannot be implemented as extensions and are sufficiently
compelling
>> it was designed for profile-sharing.
>>
>
> Yes, and that was never made a reality, as support for Mozilla Suite
> dropped before that was "finished" (or so I've been told in my time here).
More like Netscape did a little work to share specific prefs between the
suite and their AIM client... nobody ever finished the implementation and
the complexity wasn't worth it for a feature that didn't do anything useful
without the separate AIM client.
--BDS
Justin Wood (Callek)
> Justin Wood (Callek) wrote:
>
>> Theres no use-case for it in "Firefox", but I'd say Enigmail is a great
>> use-case for it in the platform. How about cases where an XULRunner app
>> would want to run "make check" on a build, and report the results in a
>> human readable way, via what this IPC provides, etc...
>
> Just because "X could use it" doesn't mean we should ship it in the
> platform... it's pretty clear that IPC mechanisms can be made as extensions,
> and so we should bias towards that solution unless there's a compelling
> reason why it should be shared. Those reasons might be:
>
> * features we want to expose consistently to web content
> * features that cannot be implemented as extensions and are sufficiently
> compelling
>
I guess I could argue for the micro formats removal from Firefox 3 based
on this; as it doesn't seem like the "core" code will be made into a
front-end feature. And the "toolkit/" portion(s) of it do not seem to be
available to web-content. And the actual UI for it *is* being developed
as an extension. [If I am wrong on micro formats forgive me I have not
*fully* investigated their uses]
For the record though, I wouldn't want micro formats removed, but it
seems like the reason it stays is because "there is a chance it could be
useful to Firefox", not "there is a chance it could be useful to the
platform".
On the flip-side, if your statement was a wide-sweeping one, I could
understand it. But I still don't see the underlying reason for the
switch in "we will take it if it is done" vs "No way" as you say now.
>>> it was designed for profile-sharing.
>>>
>> Yes, and that was never made a reality, as support for Mozilla Suite
>> dropped before that was "finished" (or so I've been told in my time here).
>
> More like Netscape did a little work to share specific prefs between the
> suite and their AIM client... nobody ever finished the implementation and
> the complexity wasn't worth it for a feature that didn't do anything useful
> without the separate AIM client.
>
--Fair, I never claimed to know the *specific* people taht were working
on it, and support did drop completely when "Mozilla Suite" support
dropped as well.
Justin Wood (Callek)
To actually cite a source:
https://bugzilla.mozilla.org/show_bug.cgi?id=68702#c116
"Not a blocker, but we'd take it."~Benjamin Smedberg [:bs] (bsmedberg)
2007-02-01 07:06:38 PST
Now I surely am not claiming "but we'd take it" to mean "Gecko 1.9" as I
said above.
~Justin Wood (Callek)
Patrick Brunschwig
I can work on making IPC compliant to frozen linkage. I actually already
converted quite a large part some months ago (that's in the current
trunk), but I never completed it until the very end. If someone has some
patches, I'd certainly accept them as well ;-)
-Patrick
Mike Shaver
> Benjamin Smedberg wrote:
> > * features we want to expose consistently to web content
> on this; as it doesn't seem like the "core" code will be made into a
> front-end feature.
I don't think that would be fruitful -- if you _are_ arguing for it,
please just do so. Anyone _could_ argue about anything, as you can
see only too readily in our mailing lists, so please take a position
and state it clearly without a million hedges and could-bes. If you
believe that IPC should be in the core code, because it's the right
set of minimal primitives to add to the platform, it is of high enough
quality with active maintainership, tests, etc., then make that case
-- and I do mean _make_ that case, not allude to the possibility that
someone might possibly make the case -- in the IPC bug that you
reference.
Microformat code operates on web content, and we want it to be
consistent. It is also actively maintained, and I believe has a test
suite.
Mike
Robert Kaiser
> Just because "X could use it" doesn't mean we should ship it in the
> platform... it's pretty clear that IPC mechanisms can be made as extensions,
> and so we should bias towards that solution unless there's a compelling
> reason why it should be shared.
So you would be OK with that code just landing in mozilla/mailnews or
mozilla/suite as those probably want it, but keep it out of the general
platform?
Robert Kaiser
Benjamin Smedberg
If those owners review it and are willing to maintain it, sure... the
process of review for inclusion in XPCOM has mainly been slowed down by that
I see API problems that would cause me to reject it as a general solution,
and I'm afraid of taking on code ownership/maintenance.
--BDS
Justin Wood (Callek)
> Mike
Sorry mike, I do realize now after reading your post, and re-reading
mine that I was overly aggressive sounding in my last response here.
So to Ben, you, and anyone else reading, "I'm sorry".
I guess just since I have brainstormed on things I might want to do, and
how to do them for a few years with regards to "hmm, this IPC stuff
might work" does seem to clot my judgment here slightly.
I'll reply as it relates to IPC directly in response to a different post.
--
~Justin Wood (Callek)
Justin Wood (Callek)
I wonder if including it within mozilla/ipc parallel the other
implementation is ok, but not including it in the "platform" (by
default), and even maybe having two switches, one where it builds as a
component/extension the other where it builds "into the platform" would
be acceptable.
Obviously I'm not the one doing any of this work, and am just
brainstorming here; but I feel stuffing it under mozilla/suite or
mozilla/mailnews (etc.) is merely obscuring it from where (to me) in
directory structure it seems to belong.
And in hindsight I do notice that you have not explained in detail why
the change of mind; but then again, you never explained in detail why
you said yes, and I suppose a simple "I changed my mind" is enough here
:-) so I will not press that issue anymore.
Thank you for your patience with me in regard to this,
--
~Justin Wood (Callek)
Mime
wrote:
> Mime wrote:
> >> Your makefile defines MOZILLA_INTERNAL_API, which causes the code to try to
> >> link with symbols that are not available outside of libxul.
>
> > Well, so I got rid of MOZILLA_INTERNAL_API and started converting the
> > code using the guidelines listed here at
>
> HTH.
> --
> Mook
> mook dot moz plus stuff at gmail
> still scarred from xpfe search thingy
Alright, well, getting back sort of to the topic hand which is trying
to build this thing - I've got it working now. Hooray! (:happy
dance:) Thanks for your help, Mook (and Patrick!)
Anyway, the diff is here:
http://www.nightlight.ws/images/mime/media/ipc.diff
I'd like to reiterate that I'm not an expert C++ programmer (or even a
moderately good one) so if anybody could provide feedback that would
be sweet.
NOTE: One caveat - one section of the code was particularly
troublesome, the ParseHeader function in nsPipeChannel.cpp, so I just
commented it out b/c I won't be using that function in any case...so
somebody still has to convert that part over)
Mime!
Mime
Oh, another thing. In the makefile of the build directory I added:
+ $(DEPTH)/dist/lib/xpcomglue_s.lib \
but that seems a bit hacky to me. It obviously needs that file to
compile - how do I add that file cleanly?
Mime
Benjamin Smedberg
> Oh, another thing. In the makefile of the build directory I added:
> + $(DEPTH)/dist/lib/xpcomglue_s.lib \
>
> but that seems a bit hacky to me. It obviously needs that file to
> compile - how do I add that file cleanly?
EXTRA_DSO_LDOPTS += $(XPCOM_GLUE_LDOPTS)
--BDS
Mime
Thanks, Ben! (and thanks for helping out up there at the top of the
thread) Much appreciation all around, guys.
Patrick Brunschwig
[...]
>
> If those owners review it and are willing to maintain it, sure... the
> process of review for inclusion in XPCOM has mainly been slowed down by that
> I see API problems that would cause me to reject it as a general solution,
> and I'm afraid of taking on code ownership/maintenance.
Benjamin, which problems do you see precisely with the API? I know that
one area is the way executables are started (by providing a string
containing the complete command line); I have been working on changing
the API such that executables will be called in the correct way (i.e.
similarly as in nsIProcess).
I'm willing to fix the API issues, but it would be helpful to know a bit
more concretely where the problems are.
-Patrick