Re: build svtools and sw with debug
Hi, On 27.09.2012 16:11, Ariel Constenla-Haile wrote: Hi Pedro, * On Wed, Sep 26, 2012 at 08:47:31AM -0700, Pedro Giffuni wrote: Please note that many people did Windows (and linux and MacOSX) builds just fine with the new boost. There was a problem similar to the one recently reported that was fixed by orw@ but, from what we discussed, there was no need to revert the boost update (and yes, I did offer to revert it then). The solution provided by Oliver removed the header, and the use of the boost smart pointer with it, it helped to go on with the build, just like Armin's solution; but the build still breaks in sw in a PRO build with DEBUG=yes. So the problem is still there, and started coincidentally with boost update. It looks like the only way to know if this was a coincide, or the root cause, is to revert in a local build the boost update, build a PRO version, and see if building with debugging symbols sw breaks or not. I can confirm that an PRO build (_not_ using configure option --enable-dbgutil) with DEBUG=yes breaks in module sw. To fix this build breaker you need to add link library stl into library swd - a similar change as the one which Armin made in module svtools. I NON-PRO build (using configure option --enable-dbgutil) without DEBUG works fine. I had just started a NON-PRO build with DEBUG=yes - I will provide the build results later. Best regards, Oliver.
Re: build svtools and sw with debug
Hi Oliver; - Original Message - ... > > I can confirm that an PRO build (_not_ using configure option > --enable-dbgutil) > with DEBUG=yes breaks in module sw. > To fix this build breaker you need to add link library stl into library swd - > a > similar change as the one which Armin made in module svtools. > > I NON-PRO build (using configure option --enable-dbgutil) without DEBUG works > fine. > > I had just started a NON-PRO build with DEBUG=yes - I will provide the build > results later. > > > Best regards, Oliver. > The big question here, at least for me, is why a boost update causes trouble to stlport and why it only affects Windows. Looking around, the update didn't include normalizing all the headers. I fixed that in r1391078, but it would surprise me if it has any real effect: in theory we are not (yet) using the new headers. Pedro.
Re: build svtools and sw with debug
On Thu, Sep 27, 2012 at 09:27:23AM -0700, Pedro Giffuni wrote: > The big question here, at least for me, is why a boost update causes trouble > to stlport and why it only affects Windows. Google lead me to http://boost.2283326.n4.nabble.com/Can-t-build-boost-1-48-with-STLport-5-2-1-td4372308.html "My best guess is the /D_STLP_DEBUG define which enables enhanced debugging magic (iterator validation etc.) which might not be binary compatible with Boost." The fanny thing is that _STLP_DEBUG is defined only for non pro build. We may need some boost guru to find out what's happening. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp0Wt3WagHyf.pgp Description: PGP signature
Re: build svtools and sw with debug
Hi Ariel; > From: Ariel Constenla-Haile > > On Thu, Sep 27, 2012 at 09:27:23AM -0700, Pedro Giffuni wrote: >> The big question here, at least for me, is why a boost update causes >> trouble to stlport and why it only affects Windows. > > Google lead me to > http://boost.2283326.n4.nabble.com/Can-t-build-boost-1-48-with-STLport-5-2-1-td4372308.html > > "My best guess is the /D_STLP_DEBUG define which enables enhanced > debugging magic (iterator validation etc.) which might not be binary > compatible with Boost." > Nice find! The debugging capabilities in stlport are indeed considered an important advantage over other implementations. According to OpenGrok we define that macro in STLport-4.5.patch and a bunch of other places. > The fanny thing is that _STLP_DEBUG is defined only for non pro build. > We may need some boost guru to find out what's happening. > Or an STLport guru. cheers, Pedro.
Re: build svtools and sw with debug
Answering to myself ... - Original Message - > From: Pedro Giffuni ... > > Hi Ariel; > >> From: Ariel Constenla-Haile > >> >> On Thu, Sep 27, 2012 at 09:27:23AM -0700, Pedro Giffuni wrote: >>> The big question here, at least for me, is why a boost update causes >>> trouble to stlport and why it only affects Windows. >> >> Google lead me to >> > http://boost.2283326.n4.nabble.com/Can-t-build-boost-1-48-with-STLport-5-2-1-td4372308.html >> >> "My best guess is the /D_STLP_DEBUG define which enables enhanced >> debugging magic (iterator validation etc.) which might not be binary >> compatible with Boost." >> > > Nice find! The debugging capabilities in stlport are indeed considered an > important advantage over other implementations. According to OpenGrok > we define that macro in STLport-4.5.patch and a bunch of other places. > Actually, the key definition is here: http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/solenv/inc/settings.mk#894 We already ignore USE_STLP_DEBUG for OS2. Should we add Windows to the list? Pedro.
Re: build svtools and sw with debug
Hi, On 27.09.2012 17:16, Oliver-Rainer Wittmann wrote: Hi, On 27.09.2012 16:11, Ariel Constenla-Haile wrote: Hi Pedro, * On Wed, Sep 26, 2012 at 08:47:31AM -0700, Pedro Giffuni wrote: Please note that many people did Windows (and linux and MacOSX) builds just fine with the new boost. There was a problem similar to the one recently reported that was fixed by orw@ but, from what we discussed, there was no need to revert the boost update (and yes, I did offer to revert it then). The solution provided by Oliver removed the header, and the use of the boost smart pointer with it, it helped to go on with the build, just like Armin's solution; but the build still breaks in sw in a PRO build with DEBUG=yes. So the problem is still there, and started coincidentally with boost update. It looks like the only way to know if this was a coincide, or the root cause, is to revert in a local build the boost update, build a PRO version, and see if building with debugging symbols sw breaks or not. I can confirm that an PRO build (_not_ using configure option --enable-dbgutil) with DEBUG=yes breaks in module sw. To fix this build breaker you need to add link library stl into library swd - a similar change as the one which Armin made in module svtools. I NON-PRO build (using configure option --enable-dbgutil) without DEBUG works fine. I had just started a NON-PRO build with DEBUG=yes - I will provide the build results later. Just for completeness: my NON-PRO build with DEBUG=yes failed in module sw - same error as the other builds and fixed by linking swd against library stl. Best regards, Oliver.
Re: build svtools and sw with debug
Hi, On 27.09.2012 21:54, Pedro Giffuni wrote: Answering to myself ... - Original Message - From: Pedro Giffuni ... Hi Ariel; From: Ariel Constenla-Haile On Thu, Sep 27, 2012 at 09:27:23AM -0700, Pedro Giffuni wrote: The big question here, at least for me, is why a boost update causes trouble to stlport and why it only affects Windows. Google lead me to http://boost.2283326.n4.nabble.com/Can-t-build-boost-1-48-with-STLport-5-2-1-td4372308.html "My best guess is the /D_STLP_DEBUG define which enables enhanced debugging magic (iterator validation etc.) which might not be binary compatible with Boost." Nice find! The debugging capabilities in stlport are indeed considered an important advantage over other implementations. According to OpenGrok we define that macro in STLport-4.5.patch and a bunch of other places. Actually, the key definition is here: http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/solenv/inc/settings.mk#894 We already ignore USE_STLP_DEBUG for OS2. Should we add Windows to the list? Not having CDEFS+=-D_STLP_DEBUG means that we will have no additional checking stuff in a DEBUG=yes build. Right? My current impression is the following: - the new boost version makes more or different use of stl - we are not building with the "right" compiler and link switches in DEBUG=yes builds. - the three needed adjustments to module setup_native, svtools and sw avoid the build breakers. I am not sure, if they are only workaround Best regards, Oliver.
Re: build svtools and sw with debug
--- Ven 28/9/12, Oliver-Rainer Wittmann ha scritto: > Da: Oliver-Rainer Wittmann . > >> > > > > Actually, the key definition is here: > > > > http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/solenv/inc/settings.mk#894 > > > > We already ignore USE_STLP_DEBUG for OS2. Should we add > Windows to the list? > > > > Not having CDEFS+=-D_STLP_DEBUG means that we will have no > additional checking stuff in a DEBUG=yes build. Right? > It means we lose the STLport specific debugging. We will lose it anyway when we drop STLport. > > My current impression is the following: > - the new boost version makes more or different use of stl Newer boost appears to have its own debugging support, but I havent looked into it. > - we are not building with the "right" compiler and link > switches in DEBUG=yes builds. Yes, this is something important to review. We could be getting better information for MSVC. > - the three needed adjustments to module setup_native, > svtools and sw avoid the > build breakers. I am not sure, if they are only workaround > I tend to agree here too. Pedro.