Apache OpenOffice (AOO) Bugzilla – Issue 77422
to-be-SRC680_m212: cppu compile issue in AffineBridge.cxx
Last modified: 2007-09-27 12:51:36 UTC
unxlngx6: /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/AffineBridge/AffineBridge.cxx: In member function 'virtual void AffineBridge::v_callInto_v(void (*)(__va_list_tag*), __va_list_tag*)': /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/AffineBridge/AffineBridge.cxx:276: error: incompatible types in assignment of '__va_list_tag*' to '__va_list_tag [1]' /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/AffineBridge/AffineBridge.cxx: In member function 'virtual void AffineBridge::v_callOut_v(void (*)(__va_list_tag*), __va_list_tag*)': /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/AffineBridge/AffineBridge.cxx:309: error: incompatible types in assignment of '__va_list_tag*' to '__va_list_tag [1]'
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
kr: citation from http://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html But va_list is an opaque type and one cannot necessarily assign the value of one variable of type va_list to another variable of the same type.
This should work: #ifdef __va_copy __va_copy (m_param, param); #else m_param = param; #endif in fact it at least compiles here and then: /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx: In function 'void s_pull (__va_list_tag*)': /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:231: warning: cannot receive objects of non-POD type 'struct __va_list_tag [1]' through '...'; call will abort at runtime /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:231: error: invalid initializer /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx: In function 'void s_environment_invoke_vv(__va_list_tag*)': /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:281: warning: cannot receive objects of non-POD type 'struct __va_list_tag [1]' through '...'; call will abort at runtime /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/uno/EnvStack.cxx:281: error: invalid initializer dmake: Error code 1, while making '../../unxlngx6.pro/slo/EnvStack.obj'
In EnvStack.cxx, the problem is: uno_EnvCallee * pCallee = va_arg(param, uno_EnvCallee *); va_list xparam = va_arg(param, va_list); pCallee(xparam); It should probably read uno_EnvCallee * pCallee = va_arg(param, uno_EnvCallee *); va_arg(param, va_list); pCallee(param); But I do not know what is in param. This one extects, we have to skip one argument after pCallee itself... va_arg docs says: --- cut here --- * Macro: type va_arg (va_list ap, type) The va_arg macro returns the value of the next optional argument, and modifies the value of ap to point to the subsequent argument. Thus, successive uses of va_arg return successive optional arguments. --- cut here --- So probably we skip one argument *after* pCallee unintentionally?
So, is simple uno_EnvCallee * pCallee = va_arg(param, uno_EnvCallee *); pCallee(param); enough?
Pavel, your first fix regarding the use of "__va_copy_" looks reasonable. Unfortunately the second one does not ;-( Are their any buildbots or similar where I can reproduce the problem to fix this? Regards Kay
Created attachment 45141 [details] Fix for gcc 64
Pavel, could you try the attached patch? It at least compiles on 32bit ... ;-)
Reassigned to me.
started ...
cc
Will do immediatelly after dinner - ~30 minutes.
Yes, the patch fixed also the second break. With fixed /tmp/AffineBridge.cxx I now get this: Making: ../unxlngx6.pro/lib/libunsafe_uno_uno.so ccache /usr//bin/g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared -L../unxlngx6.pro/ lib -L../lib -L/data/oo/BuildDir/ooo_SRC680_m212_src/solenv/unxlngx6/lib -L/data/oo/BuildDir/ ooo_SRC680_m212_src/solver/680/unxlngx6.pro/lib -L/data/oo/BuildDir/ooo_SRC680_m212_src/ solenv/unxlngx6/lib -L/opt/java/lib64 -L/opt/java/jre/lib/amd64 -L/opt/java/jre/lib/amd64/server - L/opt/java/jre/lib/amd64/native_threads -L/usr/X11R6/lib64 ../unxlngx6.pro/slo/UnsafeBridge.o ../ unxlngx6.pro/slo/unsafe_uno_uno_version.o ../unxlngx6.pro/slo/unsafe_uno_uno_description.o -o ../ unxlngx6.pro/lib/libunsafe_uno_uno.so -luno_purpenvhelpergcc3 -luno_cppu -luno_salhelpergcc3 - luno_sal -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc ../unxlngx6.pro/slo/UnsafeBridge.o: In function `uno_ext_getMapping': /data/oo/BuildDir/ooo_SRC680_m212_src/cppu/source/UnsafeBridge/UnsafeBridge.cxx:169: undefined reference to `cppu::helper::purpenv::createMapping(_uno_Mapping**, _uno_Environment*, _uno_Environment*, void (*)(bool, void*, void*, _typelib_TypeDescriptionReference*, _typelib_MethodParameter*, int, _typelib_TypeDescription const*, void*, void**, _uno_Any**), void*)' collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxlngx6.pro/lib/libunsafe_uno_uno.so'
Created attachment 45152 [details] AffineBridge diff
BTW - contact me on IRC tomorrow - I'll give you remote ssh access to such machine.
Created attachment 45222 [details] Final fix for gcc x86-64
Created attachment 45223 [details] Support for a x86-64 map file for the purpenvhelper
Created attachment 45224 [details] The actual gcc linux x86-64 purpenvhelper mapfile.
I added two patches: * EnvStack.cxx.patch.final * util_makefile.mk.patch.final and a new map file: * util_uno_purpenvhelpergcc3.X86_64.map The previous fix for EnvStack.cxx was _wrong_ . Pavel, I also fixed the unit tests on your box, feel free to check these in, otherwise I am going to do so in another CWS.
kr: I do not like to have a different map file for 64bit platforms. This would be the first example of such specific map file. So far, it was enough to have one such file. IIRC on Linux, nonexistent symbols are ignored, so we can just add the new symbol to the original gcc3 map file, no? sb: what is your opinion on this? cppu.diff that I'll attach contains complete diff I have now. With it, testcppu also succeeds. Lowering prio, as the fix is known.
sb: please read the previous comment. I forgot to add you to CC in one step, sorry.
Created attachment 45230 [details] complete cppu diff I use now
Not that easy. The mapfile written this way would broke cppu build on Mac OS X because of non-existent symbol. Just use '?' (question mark) in the map file where both symbols differ (i and l). Verifying this fix now on all systems again...
Created attachment 45239 [details] revised complete diff (for testing)
With this, OOo compiles completely, but... I build with many languages and in the final instsetoo_native build, in the middle of packing, I get error (in the e.g. 7th language): Registering python UNO components: ###################################################### SUCCESS: Source for types.rdb: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/ bin/types.rdb SUCCESS: Source for pyuno_services.rdb: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/ unxlngx6.pro/bin/pyuno_services.rdb Systemcall: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp - register -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pr o/bin/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/ pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_nativ e/unxlngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c vnd.openoffice.pymodule:mailmerge -l com.sun.star.loader.Python 2>&1 | vnd.openoffice.pymodule:mailmerge register component 'vnd.openoffice.pymodule:mailmerge' in registry '/data/oo/BuildDir/ ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/OpenOffice/deb/services.r db/fi_inprogress_1/services.rdb' succesful! ERROR: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp -register - br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin /types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/ pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unx lngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c vnd.openoffice.pymodule:mailmerge -l com.sun.star.loader.Python 2>&1 | Systemcall: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp - register -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pr o/bin/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/ pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_nativ e/unxlngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c vnd.openoffice.pymodule:pythonscript -l com.sun.star.loader.Python 2>&1 | vnd.openoffice.pymodule:pythonscript register component 'vnd.openoffice.pymodule:pythonscript' in registry '/data/oo/BuildDir/ ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/OpenOffice/deb/service s.rdb/fi_inprogress_1/services.rdb' succesful! SUCCESS: /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/regcomp -register -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/b in/types.rdb -br /data/oo/BuildDir/ooo_SRC680_m212_src/solver/680/unxlngx6.pro/bin/ pyuno_services.rdb -r /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/u nxlngx6.pro/OpenOffice/deb/services.rdb/fi_inprogress_1/services.rdb -c vnd.openoffice.pymodule:pythonscript -l com.sun.star.loader.Python 2>&1 | Moved directory from /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/ OpenOffice/deb/services.rdb/fi_inprogress_1 to /data/oo/BuildDir/ooo_SRC 680_m212_src/instsetoo_native/unxlngx6.pro/OpenOffice/deb/services.rdb/fi_witherror_1 Removing directory /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/ OpenOffice/deb/zip/fi Removing directory /data/oo/BuildDir/ooo_SRC680_m212_src/instsetoo_native/unxlngx6.pro/ OpenOffice/deb/services.rdb/fi_witherror_1 *************************************************************** ERROR: Could not register all components! in function: create_services_rdb *************************************************************** This could be something else, but it is strange.
Pavel, it seems that "sal_Int32" is mapped to "int" on x86-64 while it is mapped to "long" on x86-32. Resulting in different marshalling etc. Is this intentionally? AFAIK, "int" is four bytes of length on both platforms (By the way, SB is on vacation this week)
kr: yes, it is intentional. It can't be long, because long is 8 bit on x86-64, thus it had to be changed to int on x86-64. And as it is long on x86, we can't change it to long there because of the same reasons (ABI changes).
Ahh, I think I understand: "sal_Int32" being "long" on x86 is the bug. -> I would be able to replace "sal_Int32" with "int" and everything would be fine (though I think the natural size would be long, but anyway ;-), while the API wouldn't look as it ought to be. (The real reason for this bug being is that "typedef"s are only aliases).
Pavel, I just talked to Thorsten Behrens about adding dedicated map files (where needed) for the x86-64, and he has the same opinion as I have, that this is the right thing to do. What makes you thing that this would be wrong?
only the maintenance burden - only just for one letter/type difference in one function...
*** Issue 77909 has been marked as a duplicate of this issue. ***
*** Issue 77910 has been marked as a duplicate of this issue. ***
Pavel, I actually think that the maintenance burden is higher, if trying to use the same map file even if it needs to be differentiated by platform. -> Going to fix this by adding a new map file.
The same problem should already have arisen in older cppuhelper, for example, where cppu::PropertySetMixinImpl::getFastPropertyValue(sal_Int32) (cppuhelper/inc/cppuhelper/propertysetmixin.hxx:1.5 l. 395) is listed as _ZThn4_N4cppu20PropertySetMixinImpl20getFastPropertyValueEl with an explicit "l" for "long" at cppuhelper/source/gcc3_linux_intel.map:1.14 l. 355. How has the problem been solved there?
Going to fix this in "unomacli64" ...
cmc->sb: We accidentally entirely missed using a map for x86_64 in the other case you mentioned, i.e. we're falling through to a "don't use a map" case in cppuhelper/source/makefile.mk theres .ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXIgcc3" SHL1VERSIONMAP=gcc3_linux_intel.map but we have no x86_64 equivalent of e.g. .ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXXgcc3" SHL1VERSIONMAP=gcc3_linux_64bit.map I should probably add a 64bit linux one to that module in another issue
@cmc: I see. salhelper/source/makefile.mk:1.26 similarly misses LINUXXgcc3, with a similarly problematic salhelper::ConditionWaiter::ConditionWaiter(salhelper::Condition&,sal_uInt32) export. @*: So, we settled on creating specific map files for LINUXXgcc3 where necessary, instead of massaging the existing LINUXIgcc3 ones? Fine with me. (Although with Mac OS X we took the other route, on the grounds that each additional map file is a maintenance burden, so if we can reduce the number of map files with only mild trickery, that is not without benefits either.) @kr: va_copy is in C99, so maybe we can assume it is available everywhere instead of conditionally using either __va_copy or some construct that is not guaranteed to do anything sensible, even if it compiles (i.e., assignment between va_list values). (Then again, va_copy can only be called if va_end is also called *in the same function*, see the C99 Standard, so the whole code is probably dubious, anyway.)
->SB: Trying to avoid that "va_copy" altogether ...
FWIW I'd be in favour of adding trickery, ? for i/l and ? for 4/8 where relevant, but I'm easy about it. If we go a separate mapfile can I suggest that we call it "gcc3_unix_64bit.map" rather than e.g. gcc3_linux_x86-64.map. Whatever way we go here I can fix up the same way the other map files that we never thought of under issue 77975.
->CMC: Actually I am more a fan of using some (env) variables to identify the correct mapping file, e.g. <name>.$(CPUNAME).map or <name>.$(COM).$(CPPUNAME).map - you get what I mean. What I really don't like is something as: .IF "$(COMNAME)"=="msci" SHL1VERSIONMAP=msvc_win32_intel.map .ELIF "$(COMNAME)"=="sunpro5" SHL1VERSIONMAP=cc5_solaris_sparc.map .ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXIgcc3" SHL1VERSIONMAP=gcc3_linux_intel.map .ELIF "$(OS)$(CPU)$(COMNAME)"=="FREEBSDIgcc3" SHL1VERSIONMAP=gcc3_linux_intel.map .ELIF "$(OS)$(CPU)$(COMNAME)"=="LINUXSgcc3" SHL1VERSIONMAP=gcc3_linux_intel.map .ELIF "$(OS)$(CPU)$(COMNAME)"=="MACOSXIgcc3" SHL1VERSIONMAP=gcc3_linux_intel.map .ELIF "$(GUI)$(COM)"=="WNTGCC" SHL1VERSIONMAP=mingw.map .ENDIF If map files share symbols, we should create a common map file and include it somehow. Would that be OK for you?
I don't feel strongly about it, just so long as it doesn't become a huge time-sink task :-)
With this patch applied, OOo dies horribly on x86_64. here is the stack trace #0 0x00002b7c63fde90a in typelib_typedescription_register () from /home/hub/OOinstall/vanilla/program/libuno_cppu.so.3 #1 0x00002b7c63e3aa3b in com::sun::star::container::cppu_detail_getUnoType () from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3 #2 0x00002b7c63e3aea9 in com::sun::star::container::cppu_detail_getUnoType () from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3 #3 0x00002b7c63e4f57e in cppu::addFactories () from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3 #4 0x00002b7c63e34966 in cppu::bootstrapInitialSF () from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3 #5 0x00002b7c63e50389 in cppu::(anonymous namespace)::defaultBootstrap_InitialComponentContext () from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3 #6 0x00002b7c63e51064 in cppu::defaultBootstrap_InitialComponentContext () from /home/hub/OOinstall/vanilla/program/libuno_cppuhelpergcc3.so.3 #7 0x000000000043472a in desktop::Desktop::CreateApplicationServiceManager () #8 0x000000000041d13b in desktop::Desktop::Init () #9 0x00002b7c628f822d in InitVCL () from /home/hub/OOinstall/vanilla/program/libvcl680lx.so #10 0x00002b7c628f848a in Window::RequestHelp () from /home/hub/OOinstall/vanilla/program/libvcl680lx.so #11 0x00002b7c628f8685 in SVMain () from /home/hub/OOinstall/vanilla/program/libvcl680lx.so #12 0x000000000041b9cf in main ()
dies on startup.
kr: wrt. the patch, I did not try it yet & did not look too well either, but typeof(param[0]) * xparam = va_arg(param, typeof(param[0]) *); looks very suspicious to me :-) On x86-64, some of the parameters (6 ints, 8 floats) are stored in registers, va_list is then a structure that points to an area where they are saved; more in http://www.x86-64.org/documentation/abi.pdf, 3.34. Didn't you want to do something like va_list xparam = va_copy( va_arg(param, va_list) ) instead, and avoid the *va_list? But maybe I am completely wrong :-)
Confirmed the same horrible death on FreeBSD/amd64. :-(
Guys, I think the problem is basically solved, actually completely avoiding va_copy etc. I am quite busy currently, but plan to check in the fixes tomorrow afternoon. Hope that is OK for you. I am likely adding i77991 to unomacli64 as well, though it seems to be an independent bug, only becoming visible by introducing the threading model changes in m212. Kay
I checked in the fixes for the affine_uno bridge and triggered a build on Solaris SPARC. Linux buildbots seem to be offline, going to try again tomorrow.
kr: It seems there are some missing pieces. See the attachment.
Created attachment 45681 [details] Plug missing pieces.
Jkim, you are right, forget to check in the fixes for "bridges" and "cppuhelper" - done now.
So, everything should work now - executed all tests (as far as they are not broken) on unxsols4, unxlngi6.pro, wntmsci10.pro. -> Pavel, you want to give it a try on x86-64.
.
Pavel, have you tried this already? Unfortunately takes a little time to set up x64 and get used to it ;-)
Yes. cws unomacli64 builds, but there still is another issue #i78284#.
->Pavel, so #i78284# still happens on unomacli64 ?
yes, as I said there at the end of comment #1.
I applied the last 2 patches to m216 and it fails with this: ccache g++ -Wreturn-type -fmessage-length=0 -c -O2 -fno-strict-aliasing -Wuninitialized -I. -I../unxlngx6.pro/inc/cppuhelper -I../unxlngx6.pro/inc/cppuhelper -I../unxlngx6.pro/inc/private -I../inc -I../inc/pch -I../inc/cppuhelper -I../inc -I../unx/inc -I../unxlngx6.pro/inc -I. -I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc/stl -I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc/external -I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc -I/home/hub/novell/OpenOffice2-m215/solenv/unxlngx6/inc -I/home/hub/novell/OpenOffice2-m215/solenv/inc -I/home/hub/novell/OpenOffice2-m215/res -I/home/hub/novell/OpenOffice2-m215/solver/680/unxlngx6.pro/inc/stl -I/home/hub/novell/OpenOffice2-m215/solenv/inc/Xp31 -I/usr/include -I/usr/X11R6/include -I. -I../res -I. -pipe -Wno-ctor-dtor-privacy -fno-use-cxa-atexit -fvisibility-inlines-hidden -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DX86_64 -DCVER=C341 -DNPTL -DGLIBC=2 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.1.0 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSRC680=SRC680 -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../unxlngx6.pro/slo/component_context.o /home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx /home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx: In function 'com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> cppu::createComponentContext(const cppu::ContextEntry_Init*, sal_Int32, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext>&)': /home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx:899: error: invalid conversion from 'void (*)(__va_list_tag (*)[1])' to 'void (*)(__va_list_tag*)' /home/hub/novell/OpenOffice2-m215/cppuhelper/source/component_context.cxx:899: error: initializing argument 1 of 'void com::sun::star::uno::Environment::invoke(void (*)(__va_list_tag*), ...) const' dmake: Error code 1, while making '../unxlngx6.pro/slo/component_context.obj' ---* tg_merge.mk *--- ERROR: Error 65280 occurred while making /home/hub/novell/OpenOffice2-m215/cppuhelper/source dmake: Error code 1, while making 'build_instsetoo_native'
->HUB, please c/o the CWS unomacli64, the patches don't reflect the latest state ...
with the whole workspace in m216 it works.
Verified in unomacli64.
Issue confirmed on Linux PowerPC too
Closing ...