When linking, the order of your command-line can be important
Occasionally, people will come on the #xulrunner or #extdev channel with a question about compiling XPCOM components. The question often goes something like this:
<IRCGuy> I’m following a tutorial on making XPCOM components, but I can’t seem to get them to compile. Can anyone tell me what my problem is?
Hint for asking a good question: IRCGuy needs to tell us some combination of 1) what tutorial he’s following, 2) what the failing command is or 3) what the error message is.
This time, IRCGuy’s compile command and error message are:
IRCGuy@IRCGuy-france:/mnt/data/IRCGuy/public/project/xpcom-test$ make g++ -I/usr/local/include/xulrunner-1.9/unstable -I/usr/local/include/xulrunner-1.9/stable -L/usr/local/lib/xulrunner-devel-1.9/lib -Wl,-rpath-link,/usr/local/bin -lxpcomglue_s -lxpcom -lnspr4 -fno-rtti -fno-exceptions -shared -Wl,-z,defs france2.cpp -o france2.so /tmp/cceFg2dD.o: In function `NSGetModule': france2.cpp:(.text+0x38c): undefined reference to `NS_NewGenericModule2(nsModuleInfo const*, nsIModule**)'
IRCGuy’s problem is a problem of link ordering: with most unix-like linkers, it is very important to list object files and libraries in the correct order. The general order you want to follow is as follows:
- Object files
- Static libraries – specific to general
- Dynamic libraries
If an object file needs a symbol, the linker will only resolve that symbol in static libraries that are later in the link line.
The corrected command:
g++ -I/usr/local/include/xulrunner-1.9/unstable -I/usr/local/include/xulrunner-1.9/stable -fno-rtti -fno-exceptions -shared -Wl,-z,defs france2.cpp -L/usr/local/lib/xulrunner-devel-1.9/lib -Wl,-rpath-link,/usr/local/bin -lxpcomglue_s -lxpcom -lnspr4 -o france2.so
Bonus tip: correct linker flags for linking XPCOM components can be found on the Mozilla Developer Center article on the XPCOM Glue. As noted in the article, xpcom components want to use the “Dependent Glue” linker strategy.
September 22nd, 2008 at 6:08 pm
Hm interesting, never knew that. But the first thing that comes to my mind is: fix the linker to work correctly no matter how “stupid” or in this case uninformed the user is.
November 27th, 2008 at 12:24 pm
[…] path. I was on IRC at the time and humph graciously offered some help, his suggestion was that my linking order from the command could be the culprit. We tried manipulating the command manually to reorder it; […]
March 7th, 2009 at 4:10 pm
[…] path. I was on IRC at the time and humph graciously offered some help, his suggestion was that my linking order from the command could be the culprit. We tried manipulating the command manually to reorder it; […]