Re: Weird MSVC compilation error
> but cygpath does not work when the directory does not exist, Ah... Thanks! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
JDK 1.7 error in autogen.sh
Hi all, I have an i5 with 8GB ram PC running Fedora 16, it has OpenJDK 1.7 pre-installed in the box. When I am issuing the command: ./autogen.sh --with-num-cpus=2, I hit the following error: checking for java... /usr/bin/java checking the installed JDK... checked (JDK 1.7.0_b147-icedtea) checking for target Java bytecode version... 1.7 configure: error: 1.7 is not a supported Java bytecode version! Error running configure at ./autogen.sh line 157. May I know how this problem could be resolve? THanks @! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: basegfx::fround and friends seems needed in windows build
Hello Michael, all, On Thu, Feb 9, 2012 at 17:39, Michael Meeks wrote: > On Wed, 2012-02-08 at 21:36 +0100, Stephan Bergmann wrote: >> On 02/08/2012 09:30 PM, Caolán McNamara wrote: >> > So there are some alternatives options to hide something from >> > callcatcher. [...] write unit tests that call it [...] >> >> I somehow like that solution best. :) > > Ditto :-) Could you please give me a hint how to do this? Thanks :-) Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OK to merge the fw? libraries in framework?
Hi *, On Fri, Feb 10, 2012 at 11:56 PM, Mathias Bauer wrote: > [...] > Windows 7 already takes 50% of the Windows market, IIRC. >From visitors of www.libreoffice.org (as gathered by piwik) 43% Windows 7 24% Windows XP 13% Linux 12% Mac OS 8% Others ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Adding Extension for Experimental Thai Spelling
As I understand it, the lack of a usable Thai spell-checker for LibreOffice (unlike, say, a Khmer spell-checker) is due to the Thai break iterator. (I had expected Thai and Khmer to face similar problems, for neither has a visible word separator and syllable boundaries are often unclear in both.) Tagging Thai script text as Khmer does not work (at least, not in Version 3.4.5); the word boundaries are still determined by the Thai break iterator. Is it possible to create an experimental alternative to the Thai break iterator that can be shared with other people as a LibreOffice extension? I would be prepared to routinely use U+200B ZERO WIDTH SPACE (ZWSP) to separate words in the Thai script, but I suspect Thais would not. Also, I can seem my first useful version fouling up the rendering of pre-existing text. I can't work out how to create a break iterator as an *extension*. Could someone please advise me how, e.g. by pointing to the documentation or an example. I can find documentation for *publishing* an extension, but that does not address *creating* an extension. Richard. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to understand why LO seems freezed for some seconds when a module is started
If it may help, here are the console messages : julien@julienPC:~/compile-libreoffice/libo/install/program$ ./soffice.bin --writer warn:configmgr:9670:1:/home/julien/compile-libreoffice/libo/configmgr/source/xcuparser.cxx:209: bad set node member in "file:///home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/../share/extensions/oooblogger/Addons.xcu" warn:configmgr:9670:1:/home/julien/compile-libreoffice/libo/configmgr/source/xcuparser.cxx:767: unknown property "SpellAndGrammarDialogImage_HC" in "file:///home/julien/.config/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu8zjols.tmp/Linguistic.xcu" warn:configmgr:9670:1:/home/julien/compile-libreoffice/libo/configmgr/source/xcuparser.cxx:209: bad set node member in "file:///home/julien/.config/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu8zjolb.tmp/Addons.xcu" warn:configmgr:9670:1:/home/julien/compile-libreoffice/libo/configmgr/source/xcuparser.cxx:209: bad set node member in "file:///home/julien/.config/libreoffice/3/user/extensions/bundled/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lu8zjolb.tmp/Addons.xcu" create vcl plugin instance with gtk version 2 24 8 Screen Resolution/Size 96*96 1600*900 19,1" Black&White 0 16777215 RGB 0xff 0xff00 0xff warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand warn:legacy.osl:9670:1:/home/julien/compile-libreoffice/libo/tools/source/fsys/urlobj.cxx:3471: INetURLObject::checkHierarchical vnd.sun.star.expand I'm on pc Debian x86-64, gcc (Debian 4.6.2-12) 4.6.2 Master branch updated today. java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b24~pre2-1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) autogen.lastrun : --enable-symbols --enable-ext-barcode --enable-ext-diagram --enable-ext-google-docs --enable-ext-hunart --enable-ext-languagetool --enable-ext-nlpsolver --enable-ext-ct2n --enable-ext-numbertext --enable-ext-oooblogger --enable-ext-pdfimport --enable-ext-postgresql-sdbc --enable-ext-lightproof --enable-ext-presenter-console --enable-ext-presenter-minimizer --enable-ext-report-builder --enable-ext-scripting-beanshell --enable-ext-scripting-javascript --enable-ext-typo --enable-ext-validator --enable-ext-watch-window --enable-ext-wiki-publisher --enable-dbus --enable-graphite --enable-evolution2 --enable-werror --enable-debug --enable-dbgutil --enable-crashdump --enable-kde4 --enable-dependency-tracking --enable-online-update Julien -- View this message in context: http://nabble.documentfoundation.org/Trying-to-understand-why-LO-seems-freezed-for-some-seconds-when-a-module-is-started-tp3735600p3735606.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Trying to understand why LO seems freezed for some seconds when a module is started
Hello, On master branch (not on 3.5 branch), each time I start a module Calc, Writer or Impress (I didn't test on others), when I begin to type something, it seems to freeze for some seconds (about 10 secs) then everything seems ok. So I runned valgrind by using this : valgrind --tool=memcheck --num-callers=50 --trace-children=yes ./soffice.bin 2>&1 | tee /tmp/valgrind.log With this, I can't start LO at all because there are too much errors. By taking a look, 98% of them are like this : ==4110== Invalid write of size 4 ==4110==at 0x2E7BE641: ??? ==4110==by 0x2E7AF437: ??? ==4110==by 0x2DA518CE: JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA50D04: JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA1EBC9: instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA1EC04: instanceKlass::call_class_initializer(Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA1ED96: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA1F218: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA1F062: instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA1F218: instanceKlass::initialize(Thread*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DCEB655: Threads::create_vm(JavaVMInitArgs*, bool*) (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2DA6F920: JNI_CreateJavaVM (in /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so) ==4110==by 0x2D376369: jfw_plugin_startJavaVirtualMachine (sunjavaplugin.cxx:725) ==4110==by 0xC934F16: jfw_startVM (framework.cxx:404) ==4110==by 0x2D139F7E: stoc_javavm::JavaVirtualMachine::getJavaVM(com::sun::star::uno::Sequence const&) (javavm.cxx:786) ==4110==by 0x2CF19F24: stoc_javaloader::JavaComponentLoader::getJavaLoader() (javaloader.cxx:179) ==4110==by 0x2CF1B6C8: stoc_javaloader::JavaComponentLoader::activate(rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Reference const&) (javaloader.cxx:378) ==4110==by 0x6AC06B2: cppu::ORegistryFactoryHelper::createModuleFactory() (factory.cxx:886) ==4110==by 0x6ABFA0F: cppu::ORegistryFactoryHelper::createInstanceEveryTime(com::sun::star::uno::Reference const&) (factory.cxx:736) ==4110==by 0x6ABE5B0: cppu::OSingleFactoryHelper::createInstanceWithContext(com::sun::star::uno::Reference const&) (factory.cxx:213) ==4110==by 0x6ABEF3C: cppu::OFactoryComponentHelper::createInstanceWithContext(com::sun::star::uno::Reference const&) (factory.cxx:489) ==4110==by 0x1150FF70: stoc_smgr::OServiceManager::createInstanceWithContext(rtl::OUString const&, com::sun::star::uno::Reference const&) (servicemanager.cxx:1191) ==4110==by 0x115106E2: stoc_smgr::OServiceManager::createInstance(rtl::OUString const&) (servicemanager.cxx:1301) ==4110==by 0x20EF8E72: framework::DispatchProvider::implts_searchProtocolHandler(com::sun::star::util::URL const&) (dispatchprovider.cxx:546) ==4110==by 0x20EF856F: framework::DispatchProvider::implts_queryFrameDispatch(com::sun::star::uno::Reference, com::sun::star::util::URL const&, rtl::OUString const&, int) (dispatchprovider.cxx:449) ==4110==by 0x20EF6B7B: framework::DispatchProvider::queryDispatch(com::sun::star::util::URL const&, rtl::OUString const&, int) (dispatchprovider.cxx:149) ==4110==by 0x2578FCF9: SwXDispatchProviderInterceptor::queryDispatch(com::sun::star::util::URL const&, rtl::OUString const&, int) (unodispatch.cxx:98) ==4110==by 0x20EFA975: framework::InterceptionHelper::queryDispatch(com::sun::star::util::URL const&, rtl::OUString const&, int) (interceptionhelper.cxx:129) ==4110==by 0x20FC546A: framework::Frame::queryDispatch(com::sun::star::util::URL const&, rtl::OUString const&, int) (frame.cxx:2068) ==4110==by 0x85A2038: svt::ToolboxController::bindListener() (toolboxcontroller.cxx:567) ==4110==by 0x85A0797: svt::ToolboxController::update() (toolboxcontroller.cxx:270) ==4110==by 0x2103AC80: framework::AddonsToolBarManager::FillToolbar(com::sun::star::uno::Sequence > const&) (addonstoolbarmanager.cxx:408) ==4110==by 0x2103F8DD: framework::AddonsToolBarWrapper::initialize(com::sun::star::uno::Sequence const&) (addonstoolbarwrapper.cxx:156) ==4110==by 0x210A25A3: framework::AddonsToolBoxFactory::createUIElement(rtl::OUString const&, com::sun::star::uno::Sequence
[PATCH] Remove unused methods from PDFI
Made available under the MPL/LGPLv3+
From 4e1c72fa61e3e8d754ff3e47afe435286dcf467b Mon Sep 17 00:00:00 2001
From: Kate Goss
Date: Sat, 11 Feb 2012 16:31:27 +
Subject: [PATCH 1/3] Remove unused pdfi::DrawXmlEmitter::GetBreakIterator()
---
sdext/source/pdfimport/tree/drawtreevisiting.cxx | 12
sdext/source/pdfimport/tree/drawtreevisiting.hxx |1 -
unusedcode.easy |1 -
3 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/sdext/source/pdfimport/tree/drawtreevisiting.cxx b/sdext/source/pdfimport/tree/drawtreevisiting.cxx
index fd08894..2913878 100644
--- a/sdext/source/pdfimport/tree/drawtreevisiting.cxx
+++ b/sdext/source/pdfimport/tree/drawtreevisiting.cxx
@@ -68,18 +68,6 @@ const ::com::sun::star::uno::Reference< ::com::sun::star::i18n::XBreakIterator >
return mxBreakIter;
}
-const ::com::sun::star::uno::Reference< ::com::sun::star::i18n::XBreakIterator >& DrawXmlEmitter::GetBreakIterator()
-{
-if ( !mxBreakIter.is() )
-{
-Reference< XComponentContext > xContext( m_rEmitContext.m_xContext, uno::UNO_SET_THROW );
-Reference< XMultiComponentFactory > xMSF( xContext->getServiceManager(), uno::UNO_SET_THROW );
-Reference < XInterface > xInterface = xMSF->createInstanceWithContext(::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("com.sun.star.i18n.BreakIterator")), xContext);
-mxBreakIter = uno::Reference< i18n::XBreakIterator >( xInterface, uno::UNO_QUERY );
-}
-return mxBreakIter;
-}
-
const ::com::sun::star::uno::Reference< ::com::sun::star::i18n::XCharacterClassification >& DrawXmlEmitter::GetCharacterClassification()
{
if ( !mxCharClass.is() )
diff --git a/sdext/source/pdfimport/tree/drawtreevisiting.hxx b/sdext/source/pdfimport/tree/drawtreevisiting.hxx
index e957448..eb9bc23 100644
--- a/sdext/source/pdfimport/tree/drawtreevisiting.hxx
+++ b/sdext/source/pdfimport/tree/drawtreevisiting.hxx
@@ -107,7 +107,6 @@ namespace pdfi
);
public:
-const ::com::sun::star::uno::Reference< ::com::sun::star::i18n::XBreakIterator >& GetBreakIterator();
const ::com::sun::star::uno::Reference< ::com::sun::star::i18n::XCharacterClassification >& GetCharacterClassification();
enum DocType{ DRAW_DOC, IMPRESS_DOC };
explicit DrawXmlEmitter(EmitContext& rEmitContext, DocType eDocType, PDFIProcessor& rProc ) :
diff --git a/unusedcode.easy b/unusedcode.easy
index 0b128a6..3e65bce 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -1386,7 +1386,6 @@ oox::xls::WorksheetHelper::getRow(int) const
oox::xls::WorksheetHelper::getRows(oox::ValueRange const&) const
oox::xls::WorksheetHelper::putFormulaString(com::sun::star::table::CellAddress const&, rtl::OUString const&) const
oox::xls::Xf::hasAnyUsedFlags() const
-pdfi::DrawXmlEmitter::GetBreakIterator()
pdfi::PDFIProcessor::sortDocument(bool)
pdfi::PDFIRawAdaptor::odfConvert(rtl::OUString const&, com::sun::star::uno::Reference const&, com::sun::star::uno::Reference const&)
psp::GetCommandLineTokenCount(rtl::OString const&)
--
1.7.9
From 481c35cf2b6cc3a0c0f1914a265544619d75010e Mon Sep 17 00:00:00 2001
From: Kate Goss
Date: Sat, 11 Feb 2012 16:44:09 +
Subject: [PATCH 2/3] Remove unused pdfi::PDFIProcessor::sortDocument(bool)
---
sdext/source/pdfimport/tree/pdfiprocessor.cxx | 10 --
sdext/source/pdfimport/tree/pdfiprocessor.hxx |1 -
unusedcode.easy |1 -
3 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/sdext/source/pdfimport/tree/pdfiprocessor.cxx b/sdext/source/pdfimport/tree/pdfiprocessor.cxx
index 2e933e5..985e5f0 100644
--- a/sdext/source/pdfimport/tree/pdfiprocessor.cxx
+++ b/sdext/source/pdfimport/tree/pdfiprocessor.cxx
@@ -908,16 +908,6 @@ void PDFIProcessor::endIndicator()
m_xStatusIndicator->end();
}
-void PDFIProcessor::sortDocument( bool bDeep )
-{
-for( std::list< Element* >::iterator it = m_pDocument->Children.begin();
- it != m_pDocument->Children.end(); ++it )
-{
-if( dynamic_cast(*it) != NULL )
-sortElements( *it, bDeep );
-}
-}
-
static bool lr_tb_sort( Element* pLeft, Element* pRight )
{
// first: top-bottom sorting
diff --git a/sdext/source/pdfimport/tree/pdfiprocessor.hxx b/sdext/source/pdfimport/tree/pdfiprocessor.hxx
index 349a4a9..314988d 100644
--- a/sdext/source/pdfimport/tree/pdfiprocessor.hxx
+++ b/sdext/source/pdfimport/tree/pdfiprocessor.hxx
@@ -109,7 +109,6 @@ namespace pdfi
sal_Int32 getFontId( const FontAttributes& rAttr ) const;
void sortElements( Element* pElement, bool bDeep = false );
-void sortDocument( bool bDeep = false );
rtl::OUString mirrorString( const rtl::OUString& i_rInString );
diff --git a/unusedcode.easy b/unusedcode.easy
index 3e65bce..b3a6ddd 100755
--- a/unusedcode.easy
+++ b/unusedcode.easy
@@ -1386,7 +1386,6 @@ oox::xls::WorksheetHelper::getRow(int) const
oox::xls::W
[PUSHED] Re: [PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
Since Riccardo was ok with your version and since it removes 1 C-cast (still 9 to convert or remove according to cppcheck :-) ), I pushed it on master. Thank you to both of you. Julien. -- View this message in context: http://nabble.documentfoundation.org/PATCH-avoid-Possible-null-pointer-dereference-in-linguistic-source-spelldsp-hxx-tp3735163p3735360.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
On 11.02.2012 20:13, julien2412 wrote: What about the Riccardo's suggestion ? Oh, it is better then mine wrt cheating cppcheck :) But I hate the hacks like ((SpellCheckerDispatcher *) this)->... A type cast from const to non-const looks like a black magic to me. Regards, Ivan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
Hello,
Il 11/02/2012 17:13, julien2412 ha scritto:
Hi Ivan,
So it would be this :
diff --git a/linguistic/source/spelldsp.hxx b/linguistic/source/spelldsp.hxx
index 9ae9cd4..e2186f9 100644
--- a/linguistic/source/spelldsp.hxx
+++ b/linguistic/source/spelldsp.hxx
@@ -73,7 +73,7 @@ class SpellCheckerDispatcher :
::com::sun::star::linguistic2::XSearchableDictionaryList>
xDicList;
LngSvcMgr&rMgr;
-linguistic::SpellCache *pCache; // Spell Cache (holds known words)
+mutable linguistic::SpellCache *pCache; // Spell Cache (holds
known words)
// disallow copy-constructor and assignment-operator for now
SpellCheckerDispatcher(const SpellCheckerDispatcher&);
@@ -134,7 +134,7 @@ public:
inline linguistic::SpellCache& SpellCheckerDispatcher::GetCache() const
{
if (!pCache)
-((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
+pCache = new linguistic::SpellCache();
return *pCache;
}
What about the Riccardo's suggestion ?
I don't know which solution would be the most appropriate and why ?
This looks more like C++ than mine :) Then it makes the code easier to
read which is always good.
cheers
--
Riccardo Magliocchetti
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
Hi Ivan,
So it would be this :
diff --git a/linguistic/source/spelldsp.hxx b/linguistic/source/spelldsp.hxx
index 9ae9cd4..e2186f9 100644
--- a/linguistic/source/spelldsp.hxx
+++ b/linguistic/source/spelldsp.hxx
@@ -73,7 +73,7 @@ class SpellCheckerDispatcher :
::com::sun::star::linguistic2::XSearchableDictionaryList >
xDicList;
LngSvcMgr &rMgr;
-linguistic::SpellCache *pCache; // Spell Cache (holds known words)
+mutable linguistic::SpellCache *pCache; // Spell Cache (holds
known words)
// disallow copy-constructor and assignment-operator for now
SpellCheckerDispatcher(const SpellCheckerDispatcher &);
@@ -134,7 +134,7 @@ public:
inline linguistic::SpellCache & SpellCheckerDispatcher::GetCache() const
{
if (!pCache)
-((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
+pCache = new linguistic::SpellCache();
return *pCache;
}
What about the Riccardo's suggestion ?
I don't know which solution would be the most appropriate and why ?
Julien.
--
View this message in context:
http://nabble.documentfoundation.org/PATCH-avoid-Possible-null-pointer-dereference-in-linguistic-source-spelldsp-hxx-tp3735163p3735284.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: OK to merge the fw? libraries in framework?
On 9 February 2012 17:29, Matúš Kukan wrote: > On 9 February 2012 15:59, Tor Lillqvist wrote: >> How is the FOO_DLLIMPLEMENTATION thing handled? Don't we in the >> --enable-mergelibs case need to add into the Library_blah.mk file for >> each library that will be part of libmerged a -DFOO_DLLIMPLEMENTATION >> for each library FOO that is part of libmerged (and that uses that >> mechanism to select between dllimport/dllexport attributes)? > > I don't know, maybe MSVC will complain, but I don't see why it had to. > All symbols should be exported properly, but maybe you are right and > the one marked with import can cause problem, > because they are in the same library and not imported from another, is > it really a problem ? I have no idea (will try later) I tried --enable-mergelibs on Windows and it is ok. (*) You only get tons of warnings like: xmlxtimp.o : warning LNK4217: locally defined symbol ??1SvXMLAttributeList@@UAE@XZ (public: virtual __thiscall SvXMLAttributeList::~SvXMLAttributeList(void)) imported in function "public: virtual void * __thiscall SvXMLAttributeList::`scalar deleting destructor'(unsigned int)" (??_GSvXMLAttributeList@@UAEPAXI@Z) I did not try to run it though, only build. Best, Matus (*) I had to remove package2 from gb_MERGEDLIBS, so there were not duplicated symbols anymore. ( Some problem with cppu::WeakImplHelper1 in package/source/zipapi/XUnbufferedStream.hxx ) Also you need http://cgit.freedesktop.org/libreoffice/core/commit/?id=484a5dcc0e0b749f58d631b957fb6f380160b7a3 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Weird MSVC compilation error
On 10 February 2012 13:57, Tor Lillqvist wrote: > Am I hallucinating or is there some weird randomness in the > Cygwin-based MSVC build nowadays? Just a moment ago I saw in > config_host.mk that ILIB didn't contain the ...solver\wntmsci12\lib > entry (which caused libxmlsec linking to fail). I started > investigating, added some debugging printouts to configure.in, and > when I now run autogen.sh, ILIB in config_host.mk *does* contain it... > Without me actually changing anything. It's not random. It's happening after make clean because ILIB is defined in configure [1] but cygpath does not work when the directory does not exist, which is the case for solver/$INPATH during configure phase. Fixed with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=636564d9b069cb4bcad8d878b5fc11b68fcc13c1 Matus [1] http://cgit.freedesktop.org/libreoffice/core/tree/configure.in#n10665 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
Hello,
Il 11/02/2012 16:21, julien2412 ha scritto:
Hello,
Cppcheck reports this :
[spelldsp.hxx:138]: (error) Possible null pointer dereference: pCache -
otherwise it is redundant to check if pCache is null at line 136
Here are the lines :
134 inline linguistic::SpellCache& SpellCheckerDispatcher::GetCache()
const
135 {
136 if (!pCache)
137 ((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
138 return *pCache;
139 }
Here is a simple (naive ?) patch
diff --git a/linguistic/source/spelldsp.hxx b/linguistic/source/spelldsp.hxx
index 9ae9cd4..34ac28f 100644
--- a/linguistic/source/spelldsp.hxx
+++ b/linguistic/source/spelldsp.hxx
@@ -134,8 +134,11 @@ public:
inline linguistic::SpellCache& SpellCheckerDispatcher::GetCache() const
{
if (!pCache)
+{
((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
-return *pCache;
+return *pCache;
+}
+return NULL;
Is it ok ?
It looks wrong to me, i'm really not into C++ but it seems
((SpellCheckerDispatcher *) this)->pCache should be the same pCache you
are dereferencing later. In any case you should not return NULL if
pCache is something else, no?
What about this?
if (pCache)
return *pCache;
return ((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
cheers,
--
Riccardo Magliocchetti
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
Hi Julien,
On 11.02.2012 19:21, julien2412 wrote:
Cppcheck reports this :
[spelldsp.hxx:138]: (error) Possible null pointer dereference: pCache -
otherwise it is redundant to check if pCache is null at line 136
Here are the lines :
134 inline linguistic::SpellCache& SpellCheckerDispatcher::GetCache()
const
135 {
136 if (!pCache)
137 ((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
138 return *pCache;
139 }
This report is a false positive. If pCache is 0, it will be created. It
seems cppcheck became confused by "(SpellCheckerDispatcher *) this"
cast. IMHO pCache should be declared as mutable and then the cast may be
removed.
Regards,
Ivan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Bug 37361] LibreOffice 3.5 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=37361 --- Comment #180 from Greg Bell 2012-02-11 07:26:52 PST --- Can't install 3.5 because it says I must quit using another version of libre -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] avoid Possible null pointer dereference in linguistic/source/spelldsp.hxx
Hello,
Cppcheck reports this :
[spelldsp.hxx:138]: (error) Possible null pointer dereference: pCache -
otherwise it is redundant to check if pCache is null at line 136
Here are the lines :
134 inline linguistic::SpellCache & SpellCheckerDispatcher::GetCache()
const
135 {
136 if (!pCache)
137 ((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
138 return *pCache;
139 }
Here is a simple (naive ?) patch
diff --git a/linguistic/source/spelldsp.hxx b/linguistic/source/spelldsp.hxx
index 9ae9cd4..34ac28f 100644
--- a/linguistic/source/spelldsp.hxx
+++ b/linguistic/source/spelldsp.hxx
@@ -134,8 +134,11 @@ public:
inline linguistic::SpellCache & SpellCheckerDispatcher::GetCache() const
{
if (!pCache)
+{
((SpellCheckerDispatcher *) this)->pCache = new
linguistic::SpellCache();
-return *pCache;
+return *pCache;
+}
+return NULL;
Is it ok ?
(if yes, I can commit and push it on master)
Julien.
--
View this message in context:
http://nabble.documentfoundation.org/PATCH-avoid-Possible-null-pointer-dereference-in-linguistic-source-spelldsp-hxx-tp3735163p3735163.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] Remove unused code (5)
On 10.02.2012 18:24, Elton Chung wrote: This patch removes 5 unused methods. Pushed, thank you. Regards, Ivan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[REVIEW 3-5] Wrong mapping to log level from postgresql-sdbc.ini
Hi all, Please review the commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=4649fafa317f4717634d863d3f3edf1d0180fc1e for cherry-pick to 3-5 if appropriate. Cheers, -- Takeshi Abe ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PUSHED] Re: Same expression on both sides of '|'
I pushed the suggestion on master (commit 5972e4db625500261d924028189793c7d51b576e) Thank you Caolán ! Julien. -- View this message in context: http://nabble.documentfoundation.org/Same-expression-on-both-sides-of-tp3731097p3735031.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
partial build not show module name on error
Hello all, If a partial build results in an error, the error message doesn't contain the module name, eg, $ /opt/lo/bin/make l10ntools --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 65280 occurred while making /cygdrive/d/libo/l10ntools/source it seems that the error is inside '', please re-run build inside this module to isolate the error and/or test your fix: build_error.log should contain the captured output of the failed module(s) --- To rebuild a specific module: /opt/lo/bin/make .clean #optional /opt/lo/bin/make when the problem is isolated and fixed, re-run '/opt/lo/bin/make' make: *** [l10ntools] Error 1 The 3 lines that missing module name are: it seems that the error is inside '', please re-run build /opt/lo/bin/make .clean #optional /opt/lo/bin/make I found that the "Oh dear" is in solenv/bin/build.pl, sub cancel_build at line 1476. and debugging tells me @broken_modules_names is empty in this case, giving my $module = shift @broken_modules_names; an empty string. But I couldn't go any further. :-) Could someone have a look? Thanks! :-) Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] glib needed only when enable_librsvg, gettext only when enable_librsvg or cross-compile
Hello all, I'm building on cygwin with --disable-librsvg, but it failed with > ERROR: The following files could not be found: > ERROR: File not found: giolo.dll > ERROR: File not found: gliblo.dll > ERROR: File not found: gmodulelo.dll > ERROR: File not found: gobjectlo.dll > ERROR: File not found: gthreadlo.dll > ERROR: File not found: intl.dll in scp2. I've opengrok-ed and found (snipped, see line numbers) [1] 1605 // RSVG and dependencies 1606 #if ! defined (SYSTEM_GETTEXT) 1614 Name = "intl.dll"; 1617 #endif 1618 1619 #if ! defined SYSTEM_GLIB 1627 Name = "gliblo.dll"; 1637 Name = "gthreadlo.dll"; 1647 Name = "gobjectlo.dll"; 1657 Name = "giolo.dll"; 1667 Name = "gmodulelo.dll"; 1670 #endif 1671 1672 #if ENABLE_LIBRSVG 1673 [blah blah] [1] http://opengrok.libreoffice.org/xref/core/scp2/source/ooo/file_library_ooo.scp#1605 I'm not sure why we says "RSVG and dependencies" (#1605) but checking for #if ENABLE_LIBRSVG is done later (#1672). So, I checked and found that 'gettext' is a dependency of: [2] glib, pango, gdk-pixbuf, librsvg, and cross_toolset which 'glib' is a dependency of: [3] libgsf, libcroco, pango, gdk-pixbuf and librsvg [2] http://opengrok.libreoffice.org/search?q=gettext&project=core&defs=&refs=&path=build.lst&hist= [3] http://opengrok.libreoffice.org/search?q=glib&project=core&defs=&refs=&path=build.lst&hist= Checked in same manners, pango, gdk-pixbuf, libgsf, and libcroco are dependencies of 'librsvg' *only*, which in turn we could say that 'glib' is a dependency of 'librsvg' only. Now, I summarize this as, if we're cross-compiling, we need 'gettext', but if we --disble-librsvg, we don't need neither 'gettext' nor 'glib'. So, I'm purposing a *partial* patch (attached) that guard #if ENABLE_LIBRSVG before glib (#1618). But I don't know how to check for cross-compiling for 'gettext', or is it related at all? Best Regards, -- Korrawit Pruegsanusak librsvg-check.diff Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Thu, Feb 09, 2012 at 05:54:39PM +, Michael Meeks wrote: > + is it ok to assign bugs to team-leads still ? > + quite attached to a push workflow, new bugs > in the area end up in mailbox (Lionel) I don't have a strong opinion on whether this happens from the very first report or after triage; both have advantages and disadvantages. Obviously, it happening after triage is a nice luxury for me (as a developer), and saves me quite some time: the bug already has the additional information that is needed to reproduce the bug, the "standard" questions have already been asked/answered, ... However, it consumes more triage/qa/... resources, and I get the impression that LibO is more resource-constrained in the triage/qa/... areas than in the pure developers area. Although maybe for Base specifically this is inverted ;) It can also be frustrating for a very clueful bugreporter to be asked questions (s)he (as a developer, but not LibO contributor) already knows are not relevant to the problem at hand. Also, I'm not sure about how to make it happen otherwise with our current community. Putting an individual as a "default assignee" (instead of libreoffice-b...@lists.fdo) is IMHO not a good long-term solution. For that, we would need per-component mailing lists, and the default assignee would be that. But I'm doubtful about the virtue of splitting the developer community in our current situation. Maybe if we use those mailing lists strictly only as the assignees and generally don't do discussion on them? On the other hand, I already don't keep up with libreoff...@l.fdo traffic :-| Ideally, the first mail I get about a bug also contains a good summary of the issue (which with bugzilla it typically doesn't if it gets assigned to me or I get added to the CC after the initial report). Going to a webbrowser to read the bug log is less good, but livable / acceptable. (Hmm... Maybe if bugzilla emailed me a complete bug log instead of just "lio...@mamane.lu added to CC" on the first mail I get, and only on the first?) While we are on the subject of Bugzilla and email, I remember seeing somewhere a bugzilla-email interface such that one could manipulate bugs by sending email instead of in a webbrowser. I'd be marginally happier if that extension was installed/enabled on fdo bugzilla. And I want a pony, too ;-) Whether > * system stdlibs for Linux universal builds ? (Stephan/Petr) It was said on the talk "the vast majority of our (Unix) users will use distro packages". That's possibly true enough, but it is *extremely* convenient for us that we can point our users at daily builds for testing. So it is useful for *us* as developers/qa guys that *our* binary builds work everywhere. Even if it is not a huge problem for our users that they have to use distro packages, it is for *us*. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Problem building the 3.5 branch on Windows, postgresql related.
On Thu, Jan 05, 2012 at 02:28:14AM -0500, Kohei Yoshida wrote: > I'm having trouble building the latest 3.5 branch on Windows. > First, the postgresql module failed to build due to it not finding > ldap.h from mozilla. I had mozilla entirely disabled (I always > had). That's a bug that is now fixed (was reported to me over dinner at FOSDEM). If Mozilla is entirely disabled, PostgreSQL should not try to use it. > So I decided to enable it to see if it would solve this. > Now the postgresql module builds, but it fails in connectivity due to > unresolved symbols (as follows). > /MAP /OPT:NOREF -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -RELEASE > -DEBUG -INCREMENTAL:NO /SUBSYSTEM:CONSOLE /DLL > -out:../../../wntmsci12.pro/bin/postgresql-sdbc-impl.uno.dll > -map:../../../wntmsci12.pro/misc/postgresql-sdbc-impl.uno.map > -def:../../../wntmsci12.pro/misc/postgresql-sdbc-impl.uno.def > -implib:../../../wntmsci12.pro/lib/ipostgresql_t2.lib > ../../../wntmsci12.pro/slo/postgresql-sdbc-impl.uno_version.obj > ../../../wntmsci12.pro/slb/postgresql-sdbc-impl.uno.lib icppu.lib > icppuhelper.lib isal.lib isalhelper.lib > C:/libo/libreoffice-3-5/solver/wntmsci12.pro/lib/libpq.lib ws2_32.lib > secur32.lib advapi32.lib shell32.lib ssleay32.lib libeay32.lib > msvcrt.lib msvcprt.lib uwinapi.lib kernel32.lib user32.lib > oldnames.lib ../../../wntmsci12.pro/misc/postgresql-sdbc-impl.uno.res >Creating library ../../../wntmsci12.pro/lib/ipostgresql_t2.lib and > object ../../../wntmsci12.pro/lib/ipostgresql_t2.exp > libpq.lib(fe-connect.obj) : error LNK2019: unresolved external symbol > _ldap_value_free_len@4 referenced in function _ldapServiceLookup That's yet another problem :-( It seems the build variable LDAPSDKLIB is not (properly) set in your build... It is supposed to contain "nsldap32v50.lib", which provides these symbols. Could I see your build environment? (In particular what is the value of "WITH_LDAP", "LDAPSDKLIB", "WITH_OPENLDAP"). -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Please remove obsolete files (?) in dev-www/bundles
Hello Thorsten, On Wed, Feb 8, 2012 at 20:10, Thorsten Behrens wrote: > They are for the 3.4 and possibly still helpful for initially > cloning that branch - I'm not particularly attached to them, but > would suggest to keep them around until 3.4 is closed for > maintenance? That's fine. :-) Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Fix typos in comments (1)
Hi, This patch fixes some typos in comments. Best Regards, Elton -- Elton Chung Administrator, Sponsor of http://mirror.layerjet.com Language Maintainer, Tester of ReactOS Project | http://reactos.org Email : el...@layerjet.com - Fix-typos-in-comments-1.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: config_host doesn't set $PATH
Hello Norbert, On Fri, Feb 10, 2012 at 23:20, Norbert Thiebaud wrote: > Fixed. Tested and it's fine now. Thanks for fixing :-) Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: opengrok not updated?
Hello Jan, On Fri, Feb 10, 2012 at 04:39, Jan Holesovsky wrote: > All should be fine after the next update run; please report back if not. IMHO It's working as it should now. Thanks :-) Best Regards, -- Korrawit Pruegsanusak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
changes in profile path in release notes for 3.5
Hi, On Linux (or Linux Gnome only ???) the profile directory for LO 3.5.0 has been move to ~/.config/libreoffice. This information should be clearly stated in the release notes for 3.5. Could somebody who knows exactly what has been modified, update the release notes? Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
