build svtools with debug
Hi List, with current trunk I cannot build svtools with debug, e.g. cd svtools make clean make clean debug=t make -sr -j8 debug=t -> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on windows. I tried to also build stlport with debug and delivered it, but does not help. Can someone help...? Output is: --8<---8<- c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/ipwin.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/WinResTarget/hatchwindowfactory/default.res Creating library c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib and object c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.exp documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic initializer for '_LocInit''(void)" (??__E_LocInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic initializer for '_IosInit''(void)" (??__E_IosInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic atexit destructor for '_LocInit''(void)" (??__F_LocInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic atexit destructor for '_IosInit''(void)" (??__F_IosInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/hatchwindowfactory.uno.dll : fatal error LNK1120: 4 unresolved externals /bin/cp: cannot stat `/cygdrive/c/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib': No such file or directory --8<---8<- Sincerely, Armin -- ALG
Re: build svtools with debug
Hi, On 26.09.2012 15:25, Armin Le Grand wrote: Hi List, with current trunk I cannot build svtools with debug, e.g. cd svtools make clean make clean debug=t make -sr -j8 debug=t -> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on windows. I tried to also build stlport with debug and delivered it, but does not help. Can someone help...? I can not help :( But I can confirm the issue - it also occurs in my Windows 7 environment. Best regards, Oliver.
Re: build svtools with debug
> From: Armin Le Grand ... > >Hi List, > >with current trunk I cannot build svtools with debug, e.g. > >cd svtools >make clean >make clean debug=t >make -sr -j8 debug=t > >-> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on >windows. > >I tried to also build stlport with debug and delivered it, but does not help. > >Can someone help...? > I can't really help but ... I think we started getting all those complains from STLport stuff after I updated boost (?!). Pedro. >Output is: > >--8<---8<- >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o > >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o > >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o > >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/ipwin.o >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/WinResTarget/hatchwindowfactory/default.res > Creating library >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib > and object >c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.exp >documentcloser.o : error LNK2019: unresolved external symbol >"__declspec(dllimport) public: __thiscall >_STL::ios_base::_Loc_init::_Loc_init(void)" >(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void >__cdecl _STL::`dynamic initializer for '_LocInit''(void)" >(??__E_LocInit@_STL@@YAXXZ) >hatchwindow.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall >_STL::ios_base::_Loc_init::_Loc_init(void)" >(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) >hatchwindowfactory.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall >_STL::ios_base::_Loc_init::_Loc_init(void)" >(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) >ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) >public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" >(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) >documentcloser.o : error LNK2019: unresolved external symbol >"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" >(__imp_??0Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl >_STL::`dynamic initializer for '_IosInit''(void)" (??__E_IosInit@_STL@@YAXXZ) >hatchwindow.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" >(__imp_??0Init@ios_base@_STL@@QAE@XZ) >hatchwindowfactory.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" >(__imp_??0Init@ios_base@_STL@@QAE@XZ) >ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) >public: __thiscall _STL::ios_base::Init::Init(void)" >(__imp_??0Init@ios_base@_STL@@QAE@XZ) >documentcloser.o : error LNK2019: unresolved external symbol >"__declspec(dllimport) public: __thiscall >_STL::ios_base::_Loc_init::~_Loc_init(void)" >(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void >__cdecl _STL::`dynamic atexit destructor for '_LocInit''(void)" >(??__F_LocInit@_STL@@YAXXZ) >hatchwindow.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall >_STL::ios_base::_Loc_init::~_Loc_init(void)" >(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) >hatchwindowfactory.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall >_STL::ios_base::_Loc_init::~_Loc_init(void)" >(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) >ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) >public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" >(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) >documentcloser.o : error LNK2019: unresolved external symbol >"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" >(__imp_??1Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl >_STL::`dynamic atexit destructor for '_IosInit''(void)" >(??__F_IosInit@_STL@@YAXXZ) >hatchwindow.o : error LNK2001: unresolved external symbol >"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" >(__imp_??1Init@ios_base@_STL@@QAE@XZ
Re: build svtools with debug
On Wed, Sep 26, 2012 at 10:32 AM, Pedro Giffuni wrote: > >> From: Armin Le Grand > ... >> >>Hi List, >> >>with current trunk I cannot build svtools with debug, e.g. >> >>cd svtools >>make clean >>make clean debug=t >>make -sr -j8 debug=t >> >>-> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on >>windows. >> >>I tried to also build stlport with debug and delivered it, but does not help. >> >>Can someone help...? >> > > I can't really help but ... I think we started getting all those complains > from STLport stuff after I updated boost (?!). > Would it make sense now to revert that commit and work on a branch to resolve remaining issues. It is very bad for the build to be broken for this long. -Rob > Pedro. > > >>Output is: >> >>--8<---8<- >>c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o >> >>c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o >> >>c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o >> >>c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/ipwin.o >>c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/WinResTarget/hatchwindowfactory/default.res >> Creating library >> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib >> and object >> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.exp >>documentcloser.o : error LNK2019: unresolved external symbol >>"__declspec(dllimport) public: __thiscall >>_STL::ios_base::_Loc_init::_Loc_init(void)" >>(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void >>__cdecl _STL::`dynamic initializer for '_LocInit''(void)" >>(??__E_LocInit@_STL@@YAXXZ) >>hatchwindow.o : error LNK2001: unresolved external symbol >>"__declspec(dllimport) public: __thiscall >>_STL::ios_base::_Loc_init::_Loc_init(void)" >>(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) >>hatchwindowfactory.o : error LNK2001: unresolved external symbol >>"__declspec(dllimport) public: __thiscall >>_STL::ios_base::_Loc_init::_Loc_init(void)" >>(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) >>ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) >>public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" >>(__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) >>documentcloser.o : error LNK2019: unresolved external symbol >>"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" >>(__imp_??0Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl >>_STL::`dynamic initializer for '_IosInit''(void)" (??__E_IosInit@_STL@@YAXXZ) >>hatchwindow.o : error LNK2001: unresolved external symbol >>"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" >>(__imp_??0Init@ios_base@_STL@@QAE@XZ) >>hatchwindowfactory.o : error LNK2001: unresolved external symbol >>"__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" >>(__imp_??0Init@ios_base@_STL@@QAE@XZ) >>ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) >>public: __thiscall _STL::ios_base::Init::Init(void)" >>(__imp_??0Init@ios_base@_STL@@QAE@XZ) >>documentcloser.o : error LNK2019: unresolved external symbol >>"__declspec(dllimport) public: __thiscall >>_STL::ios_base::_Loc_init::~_Loc_init(void)" >>(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void >>__cdecl _STL::`dynamic atexit destructor for '_LocInit''(void)" >>(??__F_LocInit@_STL@@YAXXZ) >>hatchwindow.o : error LNK2001: unresolved external symbol >>"__declspec(dllimport) public: __thiscall >>_STL::ios_base::_Loc_init::~_Loc_init(void)" >>(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) >>hatchwindowfactory.o : error LNK2001: unresolved external symbol >>"__declspec(dllimport) public: __thiscall >>_STL::ios_base::_Loc_init::~_Loc_init(void)" >>(__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) >>ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) >>public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" >>(__imp_??1_Loc
Re: build svtools with debug
> > From: Rob Weir ... > >On Wed, Sep 26, 2012 at 10:32 AM, Pedro Giffuni wrote: >> >>> From: Armin Le Grand >> ... >>> >>>Hi List, >>> >>>with current trunk I cannot build svtools with debug, e.g. >>> >>>cd svtools >>>make clean >>>make clean debug=t >>>make -sr -j8 debug=t >>> >>>-> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on >>>windows. >>> >>>I tried to also build stlport with debug and delivered it, but does not help. >>> >>>Can someone help...? >>> >> >> I can't really help but ... I think we started getting all those complains >> from STLport stuff after I updated boost (?!). >> > >Would it make sense now to revert that commit and work on a branch to >resolve remaining issues. It is very bad for the build to be broken >for this long. > It's not broken, just fragile. The issues so far only happen in Windows with debugging. I am afraid that if we revert the boost update we will never get the issues fixed and perhaps this is the motivation we need to resolve the stlport situation. The stlport situation is basically that we are using 3 outdated versions and it doesn't support clang. Pedro.
Re: build svtools with debug
On Wed, Sep 26, 2012 at 10:50 AM, Pedro Giffuni wrote: > >> >> From: Rob Weir > ... >> >>On Wed, Sep 26, 2012 at 10:32 AM, Pedro Giffuni wrote: >>> >>>> From: Armin Le Grand >>> ... >>>> >>>>Hi List, >>>> >>>>with current trunk I cannot build svtools with debug, e.g. >>>> >>>>cd svtools >>>>make clean >>>>make clean debug=t >>>>make -sr -j8 debug=t >>>> >>>>-> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm >>>>on windows. >>>> >>>>I tried to also build stlport with debug and delivered it, but does not >>>>help. >>>> >>>>Can someone help...? >>>> >>> >>> I can't really help but ... I think we started getting all those complains >>> from STLport stuff after I updated boost (?!). >>> >> >>Would it make sense now to revert that commit and work on a branch to >>resolve remaining issues. It is very bad for the build to be broken >>for this long. >> > > It's not broken, just fragile. The issues so far only happen in Windows with > debugging. > Having a basic function of our primary platform broken is not a minor thing. Debugging support is not optional. > I am afraid that if we revert the boost update we will never get the issues > fixed and > perhaps this is the motivation we need to resolve the stlport situation. > > The stlport situation is basically that we are using 3 outdated versions and > it > doesn't support clang. > I'm not saying updating is a bad thing. My complaint is that it broke the build. Doing it on a branch would have been better. We have a lot of components that could be updating. Should we all just check in upgrades to the trunk and pray for the best? I hope not. -Rob > Pedro.
Re: build svtools with debug
On 9/26/12 4:50 PM, Pedro Giffuni wrote: > >> >> From: Rob Weir > ... >> >> On Wed, Sep 26, 2012 at 10:32 AM, Pedro Giffuni wrote: >>> >>>> From: Armin Le Grand >>> ... >>>> >>>> Hi List, >>>> >>>> with current trunk I cannot build svtools with debug, e.g. >>>> >>>> cd svtools >>>> make clean >>>> make clean debug=t >>>> make -sr -j8 debug=t >>>> >>>> -> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm >>>> on windows. >>>> >>>> I tried to also build stlport with debug and delivered it, but does not >>>> help. >>>> >>>> Can someone help...? >>>> >>> >>> I can't really help but ... I think we started getting all those complains >>> from STLport stuff after I updated boost (?!). >>> >> >> Would it make sense now to revert that commit and work on a branch to >> resolve remaining issues. It is very bad for the build to be broken >> for this long. >> > > It's not broken, just fragile. The issues so far only happen in Windows with > debugging. > > I am afraid that if we revert the boost update we will never get the issues > fixed and > perhaps this is the motivation we need to resolve the stlport situation. I don't really share your view here and having Windows not buildable with debug is a clear no go for me. You seems to be interested in updating the boost library (which is good) but not interested to solve the upcoming problems in a way that are acceptable for all others who concentrate on other important stuff. This can't really work and I think we have to find a general agreement on how we want work together on the code. I can think of - make changes and when a build bot breaks and the problem can't be fixed easily, revert the fix - build bots on our 4 official platforms have to work always -> well something where we have to work on to reach the state that we had in the past + a Mac build bot - more difficult fixes or bigger changes should be made on branches - ... > > The stlport situation is basically that we are using 3 outdated versions and > it > doesn't support clang. In general I agree but based on the fact that we have this problems now I am in favor of doing the boost upgrade on a branch together with the stlport elimination and using the compiler stl. Juergen
Re: build svtools with debug
> From: Rob Weir ... >> I am afraid that if we revert the boost update we will never get the issues > fixed and >> perhaps this is the motivation we need to resolve the stlport situation. >> >> The stlport situation is basically that we are using 3 outdated versions > and it >> doesn't support clang. >> > > I'm not saying updating is a bad thing. My complaint is that it broke > the build. Doing it on a branch would have been better. > The build was tested in MacOS X, Linux and Windows and FreeBSD before committing. I won't be starting a branch to fix the boost update because there is nothing to fix in the boost update. > We have a lot of components that could be updating. Really? Feel free to start a wiki page so we can evaluate them, and prioritize them. At this time I only have interest on things that can help the clang port. The boost update is/was necessary: Linux/BSD builds are using the system boost (usually more updated than the one we currently have) and that means we can't detect if something doesn't work until it's too late. The real reason for the update though, is clang. Without a clang port AOO is dead in MacOSX and eventually in FreeBSD too. > just check in upgrades to the trunk and pray for the best? I hope > not. > We should *always* pray for the best. Pedro.
Re: build svtools with debug
Hi Juergen; - Original Message - > From: Jürgen Schmidt ... > > I don't really share your view here and having Windows not buildable > with debug is a clear no go for me. > You seems to be interested in updating the boost library (which is good) > but not interested to solve the upcoming problems in a way that are > acceptable for all others who concentrate on other important stuff. > I never said I am not interested in solving the problems. At this time the buildbot is broken due to many other unrelated issues and it's not clear it was my change that caused the reported issue. I am just trying to point out where things could've gone wrong. 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). This said... I am sorry but I don't do Windows and I can't help really help there beyond trivial fixes. Pedro.
Re: build svtools with debug
On 9/26/12 5:32 PM, Pedro Giffuni wrote: > > >> From: Rob Weir > ... > >>> I am afraid that if we revert the boost update we will never get the >>> issues >> fixed and >>> perhaps this is the motivation we need to resolve the stlport situation. >>> >>> The stlport situation is basically that we are using 3 outdated versions >> and it >>> doesn't support clang. >>> >> >> I'm not saying updating is a bad thing. My complaint is that it broke >> the build. Doing it on a branch would have been better. >> > > The build was tested in MacOS X, Linux and Windows and FreeBSD > before committing. I won't be starting a branch to fix the boost update > because there is nothing to fix in the boost update. > > >> We have a lot of components that could be updating. > > Really? Feel free to start a wiki page so we can evaluate them, and > prioritize them. At this time I only have interest on things that can > help the clang port. > > The boost update is/was necessary: Linux/BSD builds are using the > system boost (usually more updated than the one we currently have) > and that means we can't detect if something doesn't work until it's too > late. The real reason for the update though, is clang. Without a clang > port AOO is dead in MacOSX and eventually in FreeBSD too. nobody said it is not important, we talk here about the way to achieve in the end the same goal. Ask Armin how often he has merged the trunk back in his aw080 branch and continue the work on the branch until it is ready for trunk. The boost update as it is seems to be not ready enough and breaks other important things, in this case debug support (which is of course important for developers) on Windows. Please explain where exactly your problem is to do the work on a branch. Juergen > >> just check in upgrades to the trunk and pray for the best? I hope > >> not. >> > > We should *always* pray for the best. > > Pedro. >
Re: build svtools with debug
Hi Armin Armin Le Grand schrieb: Hi List, with current trunk I cannot build svtools with debug, e.g. cd svtools make clean make clean debug=t make -sr -j8 debug=t -> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on windows. I tried to also build stlport with debug and delivered it, but does not help. Can someone help...? I've got a debug build with MSVC 9.0 Express of r1389055. That's from Sunday 23.Sept. I've made a clean build, including "cleaning" ext_libraries. Kind regards Regina Output is: --8<---8<- c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/ipwin.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/WinResTarget/hatchwindowfactory/default.res Creating library c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib and object c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.exp documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic initializer for '_LocInit''(void)" (??__E_LocInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic initializer for '_IosInit''(void)" (??__E_IosInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic atexit destructor for '_LocInit''(void)" (??__F_LocInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::~_Loc_init(void)" (__imp_??1_Loc_init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic atexit destructor for '_IosInit''(void)" (??__F_IosInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::~Init(void)" (__imp_??1Init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init:
Re: build svtools with debug
On 9/26/12 5:47 PM, Pedro Giffuni wrote: > Hi Juergen; > > - Original Message - >> From: Jürgen Schmidt > ... >> >> I don't really share your view here and having Windows not buildable >> with debug is a clear no go for me. >> You seems to be interested in updating the boost library (which is good) >> but not interested to solve the upcoming problems in a way that are >> acceptable for all others who concentrate on other important stuff. >> > > I never said I am not interested in solving the problems. At this time > the buildbot is broken due to many other unrelated issues and it's not > clear it was my change that caused the reported issue. I am just trying > to point out where things could've gone wrong. > > 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). > > This said... I am sorry but I don't do Windows and I can't help really > help there beyond trivial fixes. yes I know and now we have a further problem that potentially is related to this. My main intention is that we agree on a general approach how we can address such problems in the future. And the easiest way is to do such changes on a branch first. Breaking a build bot is not problem as long as we can fix the problems immediately. Revert otherwise until a better fix is found. Disabling for example debug support on a platform is of course a problem that we should take serious and have to avoid. Juergen
Re: build svtools with debug
On 26.09.2012 17:57, Regina Henschel wrote: Hi Armin Armin Le Grand schrieb: Hi List, with current trunk I cannot build svtools with debug, e.g. cd svtools make clean make clean debug=t make -sr -j8 debug=t -> Lots of unresolved externals from stl. Yes, I'm using stlport, and I'm on windows. I tried to also build stlport with debug and delivered it, but does not help. Can someone help...? I've got a debug build with MSVC 9.0 Express of r1389055. That's from Sunday 23.Sept. I've made a clean build, including "cleaning" ext_libraries. That's not the problem. I've checked out yesterday and built, works well. This is a non-pro build. The problems comes up when you wahnt to build svtools with 'debug=t' to enable it for source level debugging. Thus, this is not a build breaker (as long as noone is building with debug=t for all modules) and would have not been found initially by working in a branch (implying that on a branch the diverse plattform build would have been done, noone will build single modules with debug=t there). When finding something like this I think it is not wrong to evtl. revert on trunk, go back on a branch and try to find out why a concrete case does not work (as with svtools here). I builded a lot of other modules in this working copy with debug=t, all worked well except svtools... The question is how long will we be able to live with not being able to debug in svtools on windows? Not a good situation... I just found out that svtlls part called hatchwindowfactory *can* be linked when adding the following: Index: Library_hatchwindowfactory.mk === --- Library_hatchwindowfactory.mk (revision 1389804) +++ Library_hatchwindowfactory.mk (working copy) @@ -43,6 +43,7 @@ tk \ tl \ vcl \ + stl \ $(gb_STDLIBS) \ )) @Pedro: Is this a solution? Maybe when using debug, extra stuff using stl to verify things (remember data in a vector?) gets compiled. I do not know how bad it is to always link against stl for hatchwindowfactory, even without debug build. What do You think? Kind regards Regina Output is: --8<---8<- c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/ipwin.o c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/WinResTarget/hatchwindowfactory/default.res Creating library c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib and object c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.exp documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic initializer for '_LocInit''(void)" (??__E_LocInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::_Loc_init::_Loc_init(void)" (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) referenced in function "void __cdecl _STL::`dynamic initializer for '_IosInit''(void)" (??__E_IosInit@_STL@@YAXXZ) hatchwindow.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) hatchwindowfactory.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) ipwin.o : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::ios_base::Init::Init(void)" (__imp_??0Init@ios_base@_STL@@QAE@XZ) documentcloser.o : error LNK2019: unresolved external symbol "__declspec(dllimport
Re: build svtools with debug
On 9/26/12 6:19 PM, Armin Le Grand wrote: > On 26.09.2012 17:57, Regina Henschel wrote: >> Hi Armin >> >> Armin Le Grand schrieb: >>> Hi List, >>> >>> with current trunk I cannot build svtools with debug, e.g. >>> >>> cd svtools >>> make clean >>> make clean debug=t >>> make -sr -j8 debug=t >>> >>> -> Lots of unresolved externals from stl. Yes, I'm using stlport, and >>> I'm on windows. >>> >>> I tried to also build stlport with debug and delivered it, but does not >>> help. >>> >>> Can someone help...? >> >> I've got a debug build with MSVC 9.0 Express of r1389055. That's from >> Sunday 23.Sept. I've made a clean build, including "cleaning" >> ext_libraries. > > That's not the problem. I've checked out yesterday and built, works > well. This is a non-pro build. The problems comes up when you wahnt to > build svtools with 'debug=t' to enable it for source level debugging. > > Thus, this is not a build breaker (as long as noone is building with > debug=t for all modules) and would have not been found initially by > working in a branch (implying that on a branch the diverse plattform > build would have been done, noone will build single modules with debug=t > there). > > When finding something like this I think it is not wrong to evtl. revert > on trunk, go back on a branch and try to find out why a concrete case > does not work (as with svtools here). > > I builded a lot of other modules in this working copy with debug=t, all > worked well except svtools... > > The question is how long will we be able to live with not being able to > debug in svtools on windows? Not a good situation... > > I just found out that svtlls part called hatchwindowfactory *can* be > linked when adding the following: > > Index: Library_hatchwindowfactory.mk > === > --- Library_hatchwindowfactory.mk (revision 1389804) > +++ Library_hatchwindowfactory.mk (working copy) > @@ -43,6 +43,7 @@ > tk \ > tl \ > vcl \ > + stl \ > $(gb_STDLIBS) \ > )) > > @Pedro: Is this a solution? Maybe when using debug, extra stuff using > stl to verify things (remember data in a vector?) gets compiled. I do > not know how bad it is to always link against stl for > hatchwindowfactory, even without debug build. What do You think? > > thanks Armin for your update and I would like to make clear that my interest is to find a common agreement on an approach how we can handle such problems in the future. Maybe this specific one is now solved, we will see but in general we need an approach where we can all agree on. We should continue this discussion probably in a new thread. Juergen >> Kind regards >> Regina >> >>> >>> Output is: >>> >>> --8<---8<- >>> >>> >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o >>> >>> >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o >>> >>> >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o >>> >>> >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/ipwin.o >>> >>> >>> >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/WinResTarget/hatchwindowfactory/default.res >>> >>> >>> >>> Creating library >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.lib >>> >>> >>> and object >>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/LinkTarget/Library/ihatchwindowfactory.exp >>> >>> >>> >>> documentcloser.o : error LNK2019: unresolved external symbol >>> "__declspec(dllimport) public: __thiscall >>> _STL::ios_base::_Loc_init::_Loc_init(void)" >>> (__imp_??0_Loc_init@ios_base@_STL@@QAE@XZ) referenced in function "void >>> __cdecl _STL::`dynamic initializer for '_LocInit''(void)" >>> (??__E_LocInit@_STL@@YAXXZ) >>> hatchwindow.o : error LNK2001: unresolved external symbol >>> "__declspec(dllimport) public: __thiscall >>> _STL::ios_base::_Loc_init::_Loc_init(void)" >>> (
Re: build svtools with debug
Juergen; - Original Message - ... >> >> The boost update is/was necessary: Linux/BSD builds are using the >> system boost (usually more updated than the one we currently have) >> and that means we can't detect if something doesn't work until > it's too >> late. The real reason for the update though, is clang. Without a clang >> port AOO is dead in MacOSX and eventually in FreeBSD too. > > nobody said it is not important, we talk here about the way to achieve > in the end the same goal. Ask Armin how often he has merged the trunk > back in his aw080 branch and continue the work on the branch until it is > ready for trunk. > > The boost update as it is seems to be not ready enough and breaks other > important things, in this case debug support (which is of course > important for developers) on Windows. > Please note that no one has identified yet the issue: it's highly likely that Armin has a dirty environment due to a previous (pre-boost) build but if he starts with a clean build it will go fine. Again, quite a few people reported a working debug build after the boost update. > Please explain where exactly your problem is to do the work on a branch. > Please, when we have identified the breakage cause and iff it's clear it was my update I will be glad to revert it. I really need evidence though, the changes were thoroughly tested and you cannot ask me to revert it based on Rob's sudden's feelings about it. If I do have to revert it then I will simply drop it. It works fine here. and I don't have anything to fix. Pedro.
Re: build svtools with debug
On Wed, Sep 26, 2012 at 12:27 PM, Jürgen Schmidt wrote: > On 9/26/12 6:19 PM, Armin Le Grand wrote: >> On 26.09.2012 17:57, Regina Henschel wrote: >>> Hi Armin >>> >>> Armin Le Grand schrieb: >>>> Hi List, >>>> >>>> with current trunk I cannot build svtools with debug, e.g. >>>> >>>> cd svtools >>>> make clean >>>> make clean debug=t >>>> make -sr -j8 debug=t >>>> >>>> -> Lots of unresolved externals from stl. Yes, I'm using stlport, and >>>> I'm on windows. >>>> >>>> I tried to also build stlport with debug and delivered it, but does not >>>> help. >>>> >>>> Can someone help...? >>> >>> I've got a debug build with MSVC 9.0 Express of r1389055. That's from >>> Sunday 23.Sept. I've made a clean build, including "cleaning" >>> ext_libraries. >> >> That's not the problem. I've checked out yesterday and built, works >> well. This is a non-pro build. The problems comes up when you wahnt to >> build svtools with 'debug=t' to enable it for source level debugging. >> >> Thus, this is not a build breaker (as long as noone is building with >> debug=t for all modules) and would have not been found initially by >> working in a branch (implying that on a branch the diverse plattform >> build would have been done, noone will build single modules with debug=t >> there). >> >> When finding something like this I think it is not wrong to evtl. revert >> on trunk, go back on a branch and try to find out why a concrete case >> does not work (as with svtools here). >> >> I builded a lot of other modules in this working copy with debug=t, all >> worked well except svtools... >> >> The question is how long will we be able to live with not being able to >> debug in svtools on windows? Not a good situation... >> >> I just found out that svtlls part called hatchwindowfactory *can* be >> linked when adding the following: >> >> Index: Library_hatchwindowfactory.mk >> === >> --- Library_hatchwindowfactory.mk (revision 1389804) >> +++ Library_hatchwindowfactory.mk (working copy) >> @@ -43,6 +43,7 @@ >> tk \ >> tl \ >> vcl \ >> + stl \ >> $(gb_STDLIBS) \ >> )) >> >> @Pedro: Is this a solution? Maybe when using debug, extra stuff using >> stl to verify things (remember data in a vector?) gets compiled. I do >> not know how bad it is to always link against stl for >> hatchwindowfactory, even without debug build. What do You think? >> >> > > thanks Armin for your update and I would like to make clear that my > interest is to find a common agreement on an approach how we can handle > such problems in the future. Maybe this specific one is now solved, we > will see but in general we need an approach where we can all agree on. > I think the answer would probably depend on the scope of the change. A localized change might only call for building on one platform, one configuration. But a change that is global in nature might call for a wider set of builds to confirm the correctness of the patch. Errors are unpredictable. All we really can predict is the scope of impact of an error if it occurs. So if a change could break all modules in all platforms and bring everyone's work to a screeching halt, then that suggests further diligence in that patch. Of course, this will be much easier once we have buildbot support on all platforms *and* the ability for any committer to trigger an automated build on a branch. If we make this painless then I think there would be few arguments against this. -Rob > We should continue this discussion probably in a new thread. > > Juergen > > >>> Kind regards >>> Regina >>> >>>> >>>> Output is: >>>> >>>> --8<---8<- >>>> >>>> >>>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/documentcloser.o >>>> >>>> >>>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindow.o >>>> >>>> >>>> c:/aoo/svn_trunk16/main/solver/350/wntmsci12/workdir/CxxObject/svtools/source/hatchwindow/hatchwindowfactory.o >>>> >>>> >>>> c:/aoo/svn_trun
Re: build svtools with debug
> From: Armin Le Grand ... > > I builded a lot of other modules in this working copy with debug=t, all > worked well except svtools... > > The question is how long will we be able to live with not being able to > debug in svtools on windows? Not a good situation... > > I just found out that svtlls part called hatchwindowfactory *can* be > linked when adding the following: > > Index: Library_hatchwindowfactory.mk > === > --- Library_hatchwindowfactory.mk (revision 1389804) > +++ Library_hatchwindowfactory.mk (working copy) > @@ -43,6 +43,7 @@ > tk \ > tl \ > vcl \ > + stl \ > $(gb_STDLIBS) \ > )) > > @Pedro: Is this a solution? Maybe when using debug, extra stuff using > stl to verify things (remember data in a vector?) gets compiled. I do > not know how bad it is to always link against stl for > hatchwindowfactory, even without debug build. What do You think? > Ah, I see. The problem is we would be adding a dependency to stlport *always* and in theory we are hoping to get rid of it ;-). There is no option to do --without-stlport or to skip for debug builds in our Windows build, right? :( I don't really have a problem. I have been considering two alternatives instead of getting rid of stlport: 1) There are patches to build the latest version of stlport with clang. 2) a bugzilla issue suggests apache stdcxx. Both are very difficult to implement but it's not clear that simply removing stlport and replacing it with more dependencies on boost is the way to go. In sum... yes, go ahead and add the dependency but note it carefully in the commit log so we are able to find it if we need to know later on. Pedro.
Re: build svtools with debug
Am Mittwoch, 26. September 2012 um 18:43 schrieb Pedro Giffuni: > Juergen; > > > - Original Message - > ... > > > > > > > The boost update is/was necessary: Linux/BSD builds are using the > > > system boost (usually more updated than the one we currently have) > > > and that means we can't detect if something doesn't work until > > > > > > > it's too > > > late. The real reason for the update though, is clang. Without a clang > > > port AOO is dead in MacOSX and eventually in FreeBSD too. > > > > > > > > > nobody said it is not important, we talk here about the way to achieve > > in the end the same goal. Ask Armin how often he has merged the trunk > > back in his aw080 branch and continue the work on the branch until it is > > ready for trunk. > > > > The boost update as it is seems to be not ready enough and breaks other > > important things, in this case debug support (which is of course > > important for developers) on Windows. > > > > > > > Please note that no one has identified yet the issue: it's highly likely > that Armin has a dirty environment due to a previous (pre-boost) build > but if he starts with a clean build it will go fine. Again, quite a few people > reported a working debug build after the boost update. > > see Armins mail > > > Please explain where exactly your problem is to do the work on a branch. > > > > > > > Please, when we have identified the breakage cause and iff it's clear it > was my update I will be glad to revert it. I really need evidence though, > the changes were thoroughly tested and you cannot ask me to revert it > based on Rob's sudden's feelings about it. > > it seems that you don't get my point and I was not clear enough. I am not interested in this specific case but more in a general agreement how we can address such problems. > > If I do have to revert it then I will simply drop it. It works fine here. and > I don't have anything to fix. > > Mmh, I am sure you don't mean this serious and I hope I made already clear that I wanted address this more general. You shouldn't feel attacked personally and if you do so please apologize. Juergen
Re: build svtools with debug
Hi Pedro, On 26.09.2012 20:05, Pedro Giffuni wrote: From: Armin Le Grand ... I builded a lot of other modules in this working copy with debug=t, all worked well except svtools... The question is how long will we be able to live with not being able to debug in svtools on windows? Not a good situation... I just found out that svtlls part called hatchwindowfactory *can* be linked when adding the following: Index: Library_hatchwindowfactory.mk === --- Library_hatchwindowfactory.mk (revision 1389804) +++ Library_hatchwindowfactory.mk (working copy) @@ -43,6 +43,7 @@ tk \ tl \ vcl \ + stl \ $(gb_STDLIBS) \ )) @Pedro: Is this a solution? Maybe when using debug, extra stuff using stl to verify things (remember data in a vector?) gets compiled. I do not know how bad it is to always link against stl for hatchwindowfactory, even without debug build. What do You think? Ah, I see. The problem is we would be adding a dependency to stlport *always* and in theory we are hoping to get rid of it ;-). There is no option to do --without-stlport or to skip for debug builds in our Windows build, right? :( I don't really have a problem. I have been considering two alternatives instead of getting rid of stlport: 1) There are patches to build the latest version of stlport with clang. 2) a bugzilla issue suggests apache stdcxx. Both are very difficult to implement but it's not clear that simply removing stlport and replacing it with more dependencies on boost is the way to go. In sum... yes, go ahead and add the dependency but note it carefully in the commit log so we are able to find it if we need to know later on. I committed that change, commented in the commit message. That dependency is not too bad, it will be removed (has to be removed) when we will do the STL cleanup and use only system stl. Hopefully this is not too far in the future ;-) Pedro.
Re: build svtools with debug
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. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp2a2CU0YXnj.pgp Description: PGP signature
Re: build svtools with debug
Hi Ariel and others, > From: Ariel Constenla-Haile ... > > 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. > Both issues appear to be linking related. What I am finding lately is that the build system is very fragile: it mostly works but will fail if you want to exercise it. On FreeBSD, at least: - the build fails if we try to build it with the system-jpeg. - the build doesn't detect httpclient - the option to build the lgpl libwpd doesn't build writerperfect. - Using system icu will break the build. Not to mention the patches we carry locally. I am afraid the problem is starting to take time from doing real fixes (oh yes there are still issues building with jdk7) and enhancements so I think I will be moving to the buildsys branch and focus on the build system. Pedro.
Re: build svtools with debug
Am 26.09.2012 18:19, schrieb Armin Le Grand:> > Index: Library_hatchwindowfactory.mk > === > --- Library_hatchwindowfactory.mk (revision 1389804) > +++ Library_hatchwindowfactory.mk (working copy) > @@ -43,6 +43,7 @@ > tk \ > tl \ > vcl \ > + stl \ > $(gb_STDLIBS) \ > )) > > @Pedro: Is this a solution? Maybe when using debug, extra stuff using > stl to verify things (remember data in a vector?) gets compiled. I do > not know how bad it is to always link against stl for > hatchwindowfactory, even without debug build. What do You think? Your assumption is a good one, I remember seeing this in other cases in the past. But there are other possible reasons. Using a template library might be fine without linking against its binary part, if the compiler decides to instantiate the templates in the library using the template. But sometimes the compiler decides not to do that and requires external linkage, so you have to link against the library. This may depend on compiler settings in a very subtle way, so using DEBUG might be able to trigger such a difference. That's the "beauty" of templates. :-) Especially with a compiler like the MSVC compiler that has some serious defects in this regard (I once wrote a blog about the joy of linking against symbols that contain templates on GulFOSS. Those where the days...). Regards, Mathias (who currently works with Objective-C and would love to have problems like this instead of using a programming language that neither has templates nor namespaces. But hey, at least it has closures. :-))
Workflow (was Re: build svtools with debug)
Hi Juergen; Oh.. I am not feeling any of this as a personal attack, email doesn't really represent what one thinks or how one feels about things.. It will be interesting to meet you in Germany... I suspect we are not very different ;). > > From: Juergen Schmidt > > >> >> > Please explain where exactly your problem is to do the work on a branch. >> > >> > >> >> >> Please, when we have identified the breakage cause and iff it's clear it >> was my update I will be glad to revert it. I really need evidence though, >> the changes were thoroughly tested and you cannot ask me to revert it >> based on Rob's sudden's feelings about it. >> >> > >it seems that you don't get my point and I was not clear enough. I am not >interested in this specific case but more in a general agreement how we can >address such problems. My workflow is different to what you can expect from a professional developer for many reasons, but what I tend to do is this: - My build system is based on FreeBSD's ports tree but I do use the latest code from trunk and do frequent updates from SVN. Other people's changes do affect directly what I am doing. In a certain sense this is the same as having my own local branch but some of my changes are not ready for sharing. - AOO takes long to build here so I have time to do other stuff while I wait for a build and on occasions I can be doing two orthogonal changes. Ideally I only work on one thing at a time but I can occassionally work on two. - All my changes are tested here first. - If I think the change is ready but I am not prepared to support an eventual breakage upstream, I leave it "resting" in my system for a while. - When I think the change is very system dependent I open a bugzilla issue and let it there for someone else to review. - I only do the commit when it's ready but I need to stay available to fix any eventual breakage (shit happens - I know it just too well). Before committing I always look at svn status, svn diff, and I keep a patchset ready in case I have to revert. - I am not afraid to commit. That's what lazy consensus is about. -When failure has happened I analyze quickly a solution, even if it is not optimal. If I can't fix it, I will point out where it seems to be failing and I offer to revert. Normally, like in the python update: I was able to fix it quickly and after a while I replaced the quick fix with a better one. >> >> If I do have to revert it then I will simply drop it. It works fine here. and >> I don't have anything to fix. >> >> > > Mmh, I am sure you don't mean this serious and I hope I made already clear > that I wanted address this more general. I will explain this better: my work cycle is at most two weeks for a particular task. This is unpaid work so I don't feel like spending too much time unless it's real fun. In the case of the boost update, this is something that helps the project because we have tested patches to make boost build with both gcc and clang. This is not something I *need* to have though: I already enjoy the benefits of using it as system boost. If I fail by breaking a system I don't have access to I won't stress about it: of course I will revert but if I don't have access to such system how am I going to fix it? Someone else may take over or it will be left to rust (as happens with so many things that no one has updated in AOO). If the boost change had required fixing regressions and/or optimizing other parts of the code I surely agree creating a branch was a sound approach. I think using branches is cool, but if your changes are simple (boost either builds or it doesn't) and can be handled with a single diff it is an overkill. Just my thoughts, Pedro.
