[Enigmail] building the IPC library with xulrunner-dev instead of a full build tree

[Daniel Kahn Gillmor]

Hi Patrick--

Thanks for the quick feedback!

On 03/16/2009 05:02 AM, Patrick Brunschwig wrote:
> I think it's not trivial at all. If I were you, I'd try to find out how
> Enigmail is built on Debian (i.e. download the Enigmail source package
> of Debian) and follow the way it's done there.

Yeah, i've looked at that.  It looks like they ship a snapshot of a
pruned mozilla build tree along with all the ipc source, so that they
can unpack into it and rebuild in there.  Seems like a kind of messy way
to do things, and "courtesy copies" of external code are discouraged by
debian policy anyway these days.

I've gotten further in my experimentation now than i did when i wrote
first, based tracing an in-tree build and a lot of searching the web.
i'm almost to the point of having libipc.so built, actually (though of
course i haven't tested the output).  The problem that i'm running into
is manifesting itself as a linker error at the last stage of the build.
 I've attached a gzipped tarball of the Makefiles i've cooked up that
appear to get it to build properly all the way through, but the linking
stage itself fails.  I've included the spew from the make process as
well in case anyone wants to take a look.

The problem i'm having looks a lot like http://bugs.debian.org/442966,
but the patches in that report don't seem to fix things for me.

> c++ -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long -Os -g -o libipc.so -include mozilla-config.h -include xpcom-config.h -DXPCOM_GLUE -DXPCOM_GLUE_USE_NSPR -I /usr/lib/xulrunner-devel-1.9/include -I ../src -I ../public -L /usr/lib/xulrunner-devel-1.9/lib -L /usr/lib/xulrunner-devel-1.9/bin -Wl,-rpath-link,/usr/lib/xulrunner-devel-1.9/bin -lxpcom -lxul -lnspr4 -lplds4 -lplc4 -lpthread -ldl -lnss3 -Wl,-z,defs -Wl,-h,libipc.so -Wl,--as-needed -Wl,--whole-archive ../src/libipc_s.a -Wl,--no-whole-archive /usr/lib/xulrunner-devel-1.9/sdk/lib/libxpcomglue_s.a -Wl,--version-script -Wl,components-version-script -Wl,-Bsymbolic -fno-rtti -fno-exceptions -shared -fPIC -pthread -pipe -fvisibility=hidden   nsIPCModule.o
> nsIPCModule.o: In function `NSGetModule':
> /home/builder/src/xulrunner-ipc/ipc/build/nsIPCModule.cpp:104: undefined reference to `NS_NewGenericModule2(nsModuleInfo const*, nsIModule**)'
> /usr/bin/ld: libipc.so: hidden symbol `NS_NewGenericModule2(nsModuleInfo const*, nsIModule**)' isn't defined
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status

Unfortunately, i don't really understand hidden visibility symbols in
XPCOM well enough to brute force my way through this.  Any advice would
be welcome!  I'm also happy to give interested people access to a
minimal debian sid development environment with all the build-deps
satisfied if anyone wants to poke around themselves.

Please let me know if you see me doing anything particularly horrible in
these makefiles, or if you have suggestions that you think would be better.

Regards,

	--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debian-xulrunner-ipc-makefiles.tgz
Type: application/x-gtar
Size: 2712 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/enigmail/attachments/20090316/3ce75da3/attachment.gtar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make-spew.gz
Type: application/gzip
Size: 1796 bytes
Desc: not available
URL: <http://www.mozdev.org/pipermail/enigmail/attachments/20090316/3ce75da3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: <http://www.mozdev.org/pipermail/enigmail/attachments/20090316/3ce75da3/attachment-0001.bin>