Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


I found a working solution to an issue, that I posted today, to this list ..
About using an option feature in autogen.input  

-enable-dgbutil

on a windows platform.  My builds were failing. An initial error msg was
that  build failed because it could NOT find debug libs for icu .  My
question today to this list was "what do I need to correct ? And get good
builds".

 

A solution I worked out today, corrected issues I was having with building
LibreOffice with  "-enable-dbgutil", on a Windows platform.  I verified that
correct debug lib files even for icu, were being generated.  I looked into
the /workdir/UnpackedTarBall/icu/source/lib  and the debug versions of its
range of libs had been built by this LibreOffice build system.  

 

My methodology

.         I searched the list.freedesktop.org archives for "problems with
--enable-dbgutil on Windows" and 

.         I did not find an expected series of posts answering previous
questions on how to make it work on windows.  .Really.. 

.         Nor did I find a series of post to this issue that answered with
"we are NOT having any issues building LibreOffice with option feature
'-enable-dbgutil' on windows".  

.         Nor did I get a quick answer with a solution from this list.  

.         Started a review of LibreOffice's  makefile design, and
Library<>.mk file interdependencies to discover why I was having this
problem. 

 

I tossed that investigation aside thinking that that route had been poured
over by LibreOffice experts; and took another look...

 

I didn't understand why I had to clean up this mess, with an open source
product that has been on the market, for years.. 

 

Boost libs that were built with LibreOffice's makefile system were not
conforming to boost lib naming conventions.  Checking, LibreOffice was
working with Boost  v 1 55 0.  

 

So I decided to independently build Boost v 1_55_0, all of it.  This insured
that boost libs would have a correct naming convention.  That took several
hours.  and then referred to a lib path in autogen.input. 

--with-boost-libdir=/home/lo/master/issues/boost_1_55_0/stage/lib   

 

.         Autogen worked with that option feature  "-with-boost-libdir", as
per its explicit design features spelled out in configure.

 

.         autogen.input had this option feature:

--enable-dbgutil

 

 

I will post instructions at
https://github.com/nicholasferguson/LibreOffice-Inx-for-VS2010-VS2012-dev-en
v

 

Regards

Nicholas

 

 

From: nicholas ferguson [mailto:nicholasferguson@wingarch.com] 
Sent: Tuesday, September 16, 2014 9:29 AM
To: 'libreoffice@lists.freedesktop.org'
Subject: enable-dbgutil

 

I am trying to escape having to untar all of the 3rd parties and see which
ones are missing win32 debug libs and dlls.

 

On first pass of building Libreoffice with:

--enable-dbgutil.

 

build complained that 

ExternalPackage_icu.mk:24 ...file icudtd53.dll does not exist in the
tarball.

 

So reading configure help.  I can set

--with-system-icu and do a debug build there.

 

My question:  Who can send me instructon for how many of these third party
tools have to be built that way?  And what about boost?  Libreoffice names
its boost libraries not in "boost naming style"  How do I handle that.

 

My dev environment

Cygwin64.  

A git clone of Libreoffice from trunk.

Windows 7, SDK 7.0A, DirectX SDK, MSBuild, Visual Studio 2010 Pro (trial
version)

 

 


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.