390046 - mingw build error in nsBrowserApp.cpp:133: undefined reference to _imp__XRE_GetFileFromPath

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[Martijn Wargers (dead)]

I get this build error in my mingw debug build.
Commenting out the XRE_GetFileFromPath functions fixes it (as a workaround).

-include-dir ../../dist/include/xulapp --include-dir ../../dist/include --includ
e-dir ../../dist/include --include-dir ../../dist/include/nspr -DMOZ_PNG_READ -D
PNG_NO_MMX_CODE -DMOZ_PNG_WRITE -o module.res /cygdrive/c/mozilla/mozilla/browse
r/app/module.rc
/cygdrive/c/mozilla/mozilla/build/cygwin-wrapper g++ -mno-cygwin -o firefox.exe
 -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Wove
rloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-l
ong -pedantic -mms-bitfields -pipe  -DDEBUG -D_DEBUG -DDEBUG_mw -DTRACING -g  ns
BrowserApp.o ./module.res -mconsole          -L../../dist/bin -L../../dist/lib
-lxul -L../../dist/lib -ljs3250 -L../../dist/lib -lxpcom -lxpcom_core -L../../di
st/lib -lnspr4 -lplc4 -lplds4   -lm  -lgdi32 -lwinmm -lwsock32 -lcomctl32 -lcomd
lg32 -luuid -lshell32 -lole32 -loleaut32 -lversion -lwinspool -lusp10
nsBrowserApp.o: In function `main':c:/mozilla/mozilla/browser/app/nsBrowserApp.c
pp:121: undefined reference to `_imp__XRE_GetFileFromPath'
:c:/mozilla/mozilla/browser/app/nsBrowserApp.cpp:133: undefined reference to `_i
mp__XRE_GetFileFromPath'
collect2: ld returned 1 exit status
make[5]: *** [firefox.exe] Error 1
make[5]: Leaving directory `/cygdrive/c/mozilla/mozilla/browser/app'
make[4]: *** [libs] Error 2
make[4]: Leaving directory `/cygdrive/c/mozilla/mozilla/browser'
make[3]: *** [libs_tier_app] Error 2
make[3]: Leaving directory `/cygdrive/c/mozilla/mozilla'
make[2]: *** [tier_app] Error 2
make[2]: Leaving directory `/cygdrive/c/mozilla/mozilla'
make[1]: *** [alldep] Error 2
make[1]: Leaving directory `/cygdrive/c/mozilla/mozilla'
make: *** [alldep] Error 2

Comment 1

[Martijn Wargers (dead)]

I guess this might be my own fault somehow. Some old object file hanging around?
I did a make -f client.mk distclean, but that didn't help. But manually deleting the .o files in toolkit didn't help either.
XRE_GetBinaryPath is also there and doesn't cause a build error:
http://lxr.mozilla.org/seamonkey/search?string=XRE_GetBinaryPath
http://lxr.mozilla.org/seamonkey/search?string=XRE_GetFileFromPath

Comment 2

[Martijn Wargers (dead)]

I now did a build in a complete separate directory, and I still get this build error. I'm out of ideas :(
Any help appreciated...

Comment 3

[Peter Weilbacher]

I get a similar problem when compiling in browser/app on OS/2. The linker complains

weakld: error: Unresolved symbol (UNDEF) '_XRE_GetFileFromPath'.
weakld: info: The symbol is referenced by:
    X:\trunk\fx_d\browser\app\nsBrowserApp.o
Ignoring unresolved externals reported from weak prelinker.

X:\trunk\fx_d\browser\app\nsBrowserApp.o(X:\trunk\mozilla\browser\app\nsBrowserApp.cpp) : error LNK2029: "_XRE_GetFileFromPath" : unresolved external


When I look at xul.dll I see 10 exports (e.g. XRE_main, XRE_GetBinaryPath, etc.) but XRE_GetFileFromPath is not among them. But I don't really see any difference between XRE_GetFileFromPath and XRE_GetBinaryPath causing one of them to get exported and the other not. Hmm, the latter is listed in toolkit\library\dlldeps-xul.cpp the former is not but changing that doesn't help...

Bug 321059 seems related a bit, it also lists that symbol in a linker message...

Comment 4

[Peter Weilbacher]

Attachment: working fix

OK, the difference is that XRE_GetFileFromPath comes from toolkit\profile\src which is compiled without -DIMPL_XREAPI and hence the symbol is decorated with __attribute__((dllimport)). XRE_GetBinaryPath on the other hand comes from toolkit\xre which has DEFINES += -DIMPL_XREAPI and so it gets __attribute__((dllexport)). I think that is the same on Windows and OS/2.

So simply adding DEFINES += -DIMPL_XREAPI to the profile makefile should help. Martijn, can you test this with your setup?

Comment 5

[Martijn Wargers (dead)]

Peter, thank you very much, that works here.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 280261 [details] [diff] [review]
working fix

a=bzbarsky

Comment 7

[Peter Weilbacher]

Fix checked into trunk.