Re: [dev] Was : problem building comphelper on MIPS
Hi Eric and all, On Thu, Feb 4, 2010 at 2:48 PM, eric b eric.bach...@free.fr wrote: Hi, Sorry, I missed the original message, but I'll try to answer to the original message, who is : http://www.openoffice.org/servlets/ReadMsg ?listName=devmsgNo=26295 First, I got the same issue, and I'm working on it too : OpenOffice.org can no longer be built on it, and the breakage occured between DEV300_m57 and OOO320_m12, but was very probably introduced in m58 or m59. Some details about the background now : Gdium foundation donated me a machine running a loongson processor. Since this machine is not powerfull, I prefered to port OOo4Kids on it, instead of OpenOffice.org. (but everything is similar in the build process, just more simple for OOo4Kids than OpenOffice.org). What I know is the (obsolete) OOo4Kids based on DEV300_m57 ( before important changes for 3.2.0 ) builds, and works perfectly. Since OOo4Kids has been rebased with DEV300_m12, and the build is broken (only on Mips, curiously). The first thing I found was a missing -fpic flag in the solenv/inc/ unxlngmips.mk, but I fear little other issues like that could cause the breakage. So, I can imagine the issue could be caused by some performance changes (good candidate, integration started around mDEV300_m58), probably applied by default to all Linux or something like that (just a wild guess). Investigating. Of course, anybody is welcome to help us, and any information will help too :-) Thanks in advance, Eric Bachard -- qɔᴉɹə For people who don't know, I'm colleague of the author of the original message, we build on Fuloong Minis, which has same processors as Gdium machines has. I observed the build output and found the switch still in use. The -fpic switch may have been moved to soleenv/inc/unxlng.mk in the fix of i89237 Unify the linux .mk files. If that's the case I guess there's other issues causing the breakage. Till now we have tested DEV300_m58 and DEV300_m60, the breakage took place in the latter but not the former one. By the way we tried the following workaround: adding -mips2 (or -mips3) for gcc globally, the build could continue but office will crash with SIGBUS, this can be solved by using configure --with-alloc=system as another workaround. Thanks, Felix.
Re: [dev] Was : problem building comphelper on MIPS
Le 5 févr. 10 à 09:03, Zhang Xiaofei a écrit : Hi Eric and all, Hi Felix, For people who don't know, I'm colleague of the author of the original message, we build on Fuloong Minis, which has same processors as Gdium machines has. Ok. I observed the build output and found the switch still in use. The - fpic switch may have been moved to soleenv/inc/unxlng.mk in the fix of i89237 Unify the linux .mk files. If that's the case I guess there's other issues causing the breakage. Yes you are right. In fact, after some investigations, solenv was heavily modified, and we'll have to track everything. Till now we have tested DEV300_m58 and DEV300_m60, the breakage took place in the latter but not the former one. m59 has dv14 (serious candidate for something interesting), and some other tracks. I'll continue to search what is causing the breakage. Looks like a default environment variable (mips port is maybe not complete) or something not mips adapted (to be hones, I have no clear idea in fact). By the way we tried the following workaround: adding -mips2 (or - mips3) for gcc globally, the build could continue but office will crash with SIGBUS, this can be solved by using configure --with-alloc=system as another workaround. This has to be investigated. Whet change(s) introduce -mips2 / - mips3 flags btw ? Is there a link where all this is described ? Thanks in advance :-) From my side, I'll continue to analyze the differences in solenv. Let's cross the fingers :) Eric -- qɔᴉɹə
Re: [dev] Was : problem building comphelper on MIPS
Hi Eric and all, On Thu, Feb 4, 2010 at 2:48 PM, eric b eric.bach...@free.fr wrote: Hi, Sorry, I missed the original message, but I'll try to answer to the original message, who is : http://www.openoffice.org/servlets/ReadMsg ?listName=devmsgNo=26295 First, I got the same issue, and I'm working on it too : OpenOffice.org can no longer be built on it, and the breakage occured between DEV300_m57 and OOO320_m12, but was very probably introduced in m58 or m59. Some details about the background now : Gdium foundation donated me a machine running a loongson processor. Since this machine is not powerfull, I prefered to port OOo4Kids on it, instead of OpenOffice.org. (but everything is similar in the build process, just more simple for OOo4Kids than OpenOffice.org). What I know is the (obsolete) OOo4Kids based on DEV300_m57 ( before important changes for 3.2.0 ) builds, and works perfectly. Since OOo4Kids has been rebased with DEV300_m12, and the build is broken (only on Mips, curiously). The first thing I found was a missing -fpic flag in the solenv/inc/ unxlngmips.mk, but I fear little other issues like that could cause the breakage. So, I can imagine the issue could be caused by some performance changes (good candidate, integration started around mDEV300_m58), probably applied by default to all Linux or something like that (just a wild guess). Investigating. Of course, anybody is welcome to help us, and any information will help too :-) Thanks in advance, Eric Bachard -- qɔᴉɹə For people who don't know, I'm colleague of the author of the original message, we build on Fuloong Minis, which has same processors as Gdium machines has. I observed the build output and found the switch still in use. The -fpic switch may have been moved to soleenv/inc/unxlng.mk in the fix of i89237 Unify the linux .mk files. If that's the case I guess there's other issues causing the breakage. Till now we have tested DEV300_m58 and DEV300_m60, the breakage took place in the latter but not the former one. By the way we tried the following workaround: adding -mips2 (or -mips3) for gcc globally, the build could continue but office will crash with SIGBUS, this can be solved by using configure --with-alloc=system as another workaround. Thanks, Felix.
Re: [dev] Was : problem building comphelper on MIPS
Hi Eric and all, On Thu, Feb 4, 2010 at 2:48 PM, eric b eric.bach...@free.fr wrote: Hi, Sorry, I missed the original message, but I'll try to answer to the original message, who is : http://www.openoffice.org/servlets/ReadMsg ?listName=devmsgNo=26295 First, I got the same issue, and I'm working on it too : OpenOffice.org can no longer be built on it, and the breakage occured between DEV300_m57 and OOO320_m12, but was very probably introduced in m58 or m59. Some details about the background now : Gdium foundation donated me a machine running a loongson processor. Since this machine is not powerfull, I prefered to port OOo4Kids on it, instead of OpenOffice.org. (but everything is similar in the build process, just more simple for OOo4Kids than OpenOffice.org). What I know is the (obsolete) OOo4Kids based on DEV300_m57 ( before important changes for 3.2.0 ) builds, and works perfectly. Since OOo4Kids has been rebased with DEV300_m12, and the build is broken (only on Mips, curiously). The first thing I found was a missing -fpic flag in the solenv/inc/ unxlngmips.mk, but I fear little other issues like that could cause the breakage. So, I can imagine the issue could be caused by some performance changes (good candidate, integration started around mDEV300_m58), probably applied by default to all Linux or something like that (just a wild guess). Investigating. Of course, anybody is welcome to help us, and any information will help too :-) Thanks in advance, Eric Bachard -- qɔᴉɹə For people who don't know, I'm colleague of the author of the original message, we build on Fuloong Minis, which has same processors as Gdium machines has. I observed the build output and found the switch still in use. The -fpic switch may have been moved to soleenv/inc/unxlng.mk in the fix of i89237 Unify the linux .mk files. If that's the case I guess there's other issues causing the breakage. Till now we have tested DEV300_m58 and DEV300_m60, the breakage took place in the latter but not the former one. By the way we tried the following workaround: adding -mips2 (or -mips3) for gcc globally, the build could continue but office will crash with SIGBUS, this can be solved by using configure --with-alloc=system as another workaround. Thanks, Felix.
RE: [dev] Re: dmake error: while building ucbhelper
Thanks! i will give this a try. -Original Message- From: Caolán McNamara caol...@redhat.com Sent: Tuesday, February 02, 2010 12:50 AM To: dev@openoffice.org dev@openoffice.org Subject: Re: [dev] Re: dmake error: while building ucbhelper On Mon, 2010-02-01 at 11:50 +0100, Michael Stahl wrote: On 01/02/2010 10:19, Stephan Bergmann wrote: On 02/01/10 09:23, Toufique, Imam wrote: Yes, it does. At the beginning I thought -fPIC was not being pulled in, so, I set it manually for g++. Hm, sorry, leaves me clueless. -Stephan me too. the only explanation that comes to mind is compiler and/or linker bug. I rather suspect its a problem with the visibility stuff with that SuSE compiler. i.e. unsetting HAVE_GCC_VISIBILITY_FEATURE and rebuilding that module might work. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
On Thu, 2010-02-04 at 07:48 +0100, eric b wrote: The first thing I found was a missing -fpic flag in the solenv/inc/ unxlngmips.mk -fpic is not missing from unxlngmips.mk. unxlngmips.mk inherits from unxlng.mk and unxlng.mk defaults to -fpic for PICSWITCH so unless it needs to use e.g. -fPIC then PICSWITCH doesn't need to be overridden in unxlngmips.mk C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
On Fri, 2010-02-05 at 09:19 +0100, eric b wrote:
Till now we have tested DEV300_m58 and DEV300_m60, the breakage
took place in the latter but not the former one.
And it was *definitely* the same compiler and tool chain used in both
cases right ? And the error in question is ...
comphelper/source/container/enumerablemap.cxx
{standard input}: Assembler messages:
{standard input}:714: Error: opcode not supported on this processor: mips1
(mips1) `ll $3,8($4)'
This massively looks like a toolchain issue to me and not an OOo one.
e.g. binutils/gcc target mismatch or some foo like that. I imagine that
we're talking about the normal mips o32 abi right ?, the one that gcc
defaults to out of the box for mips-linux-.
There shouldn't be anything really different about mips during the
build until bridges and the bridge test in testtools. e.g. there is
nothing in comphelper that has any mips specific stuff in there.
C.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Was : problem building comphelper on MIPS
Hi Caolan, Le 5 févr. 10 à 10:05, Caolán McNamara a écrit : On Thu, 2010-02-04 at 07:48 +0100, eric b wrote: The first thing I found was a missing -fpic flag in the solenv/inc/ unxlngmips.mk -fpic is not missing from unxlngmips.mk. unxlngmips.mk inherits from unxlng.mk and unxlng.mk defaults to -fpic for PICSWITCH so unless it needs to use e.g. -fPIC then PICSWITCH doesn't need to be overridden in Exact. My mistake: I missed it, when I compared the build in both cases. Another difference I noticed (if I'm not wrong) is , in m57 we use - DC300 ( -DC341 in OOO320 ) , and -DCVER300 (nothing similar in the OOO320), but I can be wrong. Eric -- qɔᴉɹə
Re: [dev] Was : problem building comphelper on MIPS
Hi,
Le 5 févr. 10 à 10:15, Caolán McNamara a écrit :
On Fri, 2010-02-05 at 09:19 +0100, eric b wrote:
Till now we have tested DEV300_m58 and DEV300_m60, the breakage
took place in the latter but not the former one.
And it was *definitely* the same compiler and tool chain used in
both cases right ? And the error in question is ...
Exactly : both tree on the same machine : rebuild comphelper with
DEV300_m57, and DEV300_m58 is ok.
Starting m60 - you have the issue below
comphelper/source/container/enumerablemap.cxx
{standard input}: Assembler messages:
{standard input}:714: Error: opcode not supported on this
processor: mips1
(mips1) `ll $3,8($4)'
This massively looks like a toolchain issue to me
To me too
and not an OOo one. e.g. binutils/gcc target mismatch or some foo
like that.
Well, this must be investigated anyway. I'd better vote for one
option like all linux by default or something like that. But again,
I can be wrong : I work on that just a little time per day, in my
free time.
I imagine that we're talking about the normal mips o32 abi
right ?, the one that gcc defaults to out of the box for mips-linux-.
Yes, we are. I do the chroot (linux32) like you suggested, and it was
working fine. Until one change I ignore.
There shouldn't be anything really different about mips during the
build until bridges and the bridge test in testtools. e.g. there is
nothing in comphelper that has any mips specific stuff in there.
The issue occurs in compheelper, but we agree the root is not in
comphelper. A t least, this is obvious for me.
Thanks for your time :)
Eric
--
qɔᴉɹə
Re: [dev] Was : problem building comphelper on MIPS
On Fri, 2010-02-05 at 10:30 +0100, eric b wrote: Hi, Le 5 févr. 10 à 10:15, Caolán McNamara a écrit : On Fri, 2010-02-05 at 09:19 +0100, eric b wrote: Till now we have tested DEV300_m58 and DEV300_m60, the breakage took place in the latter but not the former one. And it was *definitely* the same compiler and tool chain used in both cases right ? And the error in question is ... Exactly : both tree on the same machine : rebuild comphelper with DEV300_m57, and DEV300_m58 is ok. Starting m60 - you have the issue, Do we have logs of the exact gcc compile and link calls between pass and fail. Perhaps sometime around there some -Bsymbolic changes went in, or some extra visibility flags (don't think so) were added which triggered the underlying foo. Though it might just have been that some method randomly got large or small enough to run through a different optimization path. mips uses the -Os opt (probably copied from the Intel one originally), which is one of the less travelled gcc optimization routes as -O2 is the typical optimization. Using -O2 is worth a shot as an experiment as well, as are turning off visibility. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] building OOo 3.1.1 and OOo 3.1.0 in debugging mode and how to start the built application
Hello, I was trying to build OOo 3.1.1 and OOo 3.1.0 in debugging mode. I had the same issue as the below one. http://qa.openoffice.org/issues/show_bug.cgi?id=82773 But according to the above report, the reporter could still start open office, but I am not able to launch it. Nothing was built into the prefix directory, I am wondering after dmake debug=true, what else do we need to do before we can start the application ? Also, SRC_ROOT/instsetoo_native/ unxlngi6.pro/OpenOffice/rpm/install/en-US_witherror directory was built with 4 subdirectories/file (licenses/ readmes/ RPMS/ update* ) I am wondering could anyone give me some hints please? Thank you very much! Wei P.S.: The attached below is the last part of *log_OOO310_en-US.log: OpenOffice/rpm/logging/en-US/openoffice.org3-dict-es.spec.log Systemcall: rm -rf RPMS/buildroot Success: Executed rm -rf RPMS/buildroot successfully! Systemcall: mv RPMS/RPMS/i586/* RPMS Success: Moved content of RPMS/RPMS/i586 to RPMS! Systemcall: rmdir RPMS/RPMS/i586 Success: Removed RPMS/RPMS/i586! Systemcall: rmdir RPMS/RPMS/i386 Success: Removed RPMS/RPMS/i386! Systemcall: rmdir RPMS/RPMS Success: Removed RPMS/RPMS! Systemcall: chmod 775 RPMS /dev/null 21 Success: Executed chmod 775 RPMS /dev/null 21 successfully! Mon Feb 1 11:06:18 2010 (04:22 min.) ## Post EPM processes (Patched EPM): ## Including into installation set: openoffice.org-desktop-integration.tar.gz SUCCESS: Source for openoffice.org-desktop-integration.tar.gz: /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/bin/desktop-integration/rpm/openoffice.org-desktop-integration.tar.gz Systemcall: cd RPMS; cat /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/bin/desktop-integration/rpm/openoffice.org-desktop-integration.tar.gz| gunzip | tar -xf - Success: Executed cd RPMS; cat /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/bin/desktop-integration/rpm/openoffice.org-desktop-integration.tar.gz| gunzip | tar -xf - successfully! Mon Feb 1 11:06:18 2010 (04:22 min.) ## Start: Copying scp action files into installation set ## ... ... ... Thread: 1 :Error osl_getAsciiFunctionSymbol: /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/bin/../lib/javavm.uno.so: undefined symbol: component_getImplementationEnvironmentExt Thread: 1 :Error osl_getAsciiFunctionSymbol: /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/bin/../lib/javavm.uno.so: undefined symbol: component_canUnload Thread: 1 :Error osl_loadModule: /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/lib/libjava_gcc3.so: cannot open shared object file: No such file or directory Thread: 1 :Error osl_loadModule: /local.toadette/wei/src/ooo/ooo_3.1.1/solver/310/ unxlngi6.pro/lib/libgcc3_java.so: cannot open shared object file: No such file or directory Moved directory from /local.toadette/wei/src/ooo/ooo_3.1.1/instsetoo_native/ unxlngi6.pro/OpenOffice/rpm/install/en-US_inprogress to /local.toadette/wei/src/ooo/ooo_3.1.1/instsetoo_native/ unxlngi6.pro/OpenOffice/rpm/install/en-US_witherror *
[dev] svx module split a little bit more: new editeng module
Hi, starting with the DEV300m72 build there is a new module called editeng that was split off from svx. This module has no dependencies on svx and also no dependencies on sfx2. OTOH, svx depends on editeng (as the editengine and outliner objects are used in shapes). The moved code comprises the editeng and outliner directories, the rtf filter, many items and some other parts. Please have a look on the code and the issue cited below to see what was moved. There also have been some other code changes or movements that are explained in issue 107450: http://qa.openoffice.org/issues/show_bug.cgi?id=107450 Just to mention a few of these changes that might have some more visible influence: - class SvxLinkManager has been removed, all code now is in sfx2::LinkManager (the former base class) - svx/opengrf.hxx now is sfx2/opengrf.hxx (needed for removal of SvxLinkManager) - svx/impgrf.hxx has been removed, everything is found in svtools/filter.hxx - the function GetLanguageString now is a static method in class SvtLanguageTable - the ServiceInfoHelper class has been moved to comphelper - the function GetModuleFieldUnit has been split into two functions/methods: a function that retrieves the unit from the passed ItemSet and a new method in class SfxModule - CreateGraphicObjectFromURL now is a static method in class GraphicObject - SvxSearchItem now is in svl - HTML parser in EditEngine no longer derives from SfxHTMLParser - two static methods in SvxItemPropertySet got new boolean parameters; for convenience two functions have been added to unoshape.cxx that set them correctly for all ItemSets using the drawing pool Please keep the editeng module free from sfx2 code in future. There is absolutely no reason for that (as my experience showed me when I replaced the existing code bits by something else). This is the second step in the continuing effort to reduce the size of the svx module. Though a few unnecessary files could be removed, this will not reduce the code size of OOo, but it will create a better code separation and it helps people working on the different parts of the svx microcosmos as building the whole module will take less time. In m67 (before the work was started) we had 706 object files and 5 libraries in svx, in the cws svxsplit that just was integrated into DEV300 to become part of DEV300_m72, we will have 490 object files in 3 libraries. The code move to a new libediteng (together with moving some more code to libcui) reduced the size of the svx binaries from 7.1MB (svxcore) and 2.6MB (svx) to 5.8MB (svxcore) and 2.4MB (svx), while increasing the size of libcui from 2.9MB to 3.2MB and adding libediteng with 1.6MB. All numbers for Linux 32Bit including all other code changes made between m67 and m72. The svx resource files wa also split into svx, editeng and cui resource files. There's still room for further size reductions that could make working on svx code less time consuming. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] svx module split a little bit more: new editeng module
Hi Mathias, starting with the DEV300m72 build there is a new module called editeng that was split off from svx. ... This is the second step in the continuing effort to reduce the size of the svx module. Though a few unnecessary files could be removed, this will not reduce the code size of OOo, but it will create a better code separation and it helps people working on the different parts of the svx microcosmos as building the whole module will take less time. ... There's still room for further size reductions that could make working on svx code less time consuming. Thanks for your ongoing efforts here, that's a worthy goal, as indeed touching SVX code is a PITA right now. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] DEV300_m72: Module goodies removed
Hi, the module goodies contained a lot of unused header files, a single base3dtrans.cxx, the GraphicObject code and some graphic filters. These filters are loaded on demand and don't create any link dependencies. I moved all the filters into the module filter, the b3dtrans.cxx into tools and the GraphicObject code into svtools. The module goodies then could be removed. This change will be effective starting with DEV300_m72. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] DEV300_m72: Module goodies removed
I moved all the filters into the module filter, the b3dtrans.cxx into tools and the GraphicObject code into svtools. The module goodies then could be removed. This change will be effective starting with DEV300_m72. StarInvaders gone? -- Pavel Janík - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] DEV300_m72: Module goodies removed
Pavel Janík wrote: I moved all the filters into the module filter, the b3dtrans.cxx into tools and the GraphicObject code into svtools. The module goodies then could be removed. This change will be effective starting with DEV300_m72. StarInvaders gone? Yes. But talking about removed easter eggs looked strange to me as it never existed officially. :-) Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] the links in http://qa.openoffice.org/issues/show_bug.cgi?id=82773 are broken
Hello, I am having the same issue as http://qa.openoffice.org/issues/show_bug.cgi?id=82773, I am using the second method metioned below to make the osl less noisy. But I am curious what is the third solution really about, I was looking at TestComponent.cxx, but couldn't figure out what mean by ask installer to ignore OSL_TRACE messages. BTW, the 3 links given below seem to be broken... Thank you very much! Wei Excerpts from the website: Those messages appear because getLibEnv() probes first for the component_getImplementationEnvironmentExt and, if it's not found, continues with component_getImplementationEnvironment It seems that the former is defined only by the test component from the udk/cppuhelper/test/testcmp directory. The test component itself does not really build, but maybe this could be fixed. We can either: 1) remove any attempt to load component_getImplementationEnvironmentExt 2) make osl less noisy 3) ask installer to ignore OSL_TRACE messages I think that #3 is the best fix. References: http://lxr.go-oo.org/source/udk/cppuhelper/source/shlib.cxx#297 getLibEnv() http://lxr.go-oo.org/source/porting/sal/osl/unx/module.c#220 osl_getAsciiFunctionSymbol() http://lxr.go-oo.org/source/udk/cppuhelper/test/testcmp/TestComponent.cxx#222
