Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Oct 07, 2003 11:29 pm Post subject: Compile errors on HEAD...and fixing them...
Dan did some truly insane work over the weekend, and I just committed the last of the patches to vcl/source, so HEAD should be now complete with the 1.1 source and Neo patches. It will of course, still not compile, but it's at the phase where you can try a build and post where it's broken! Time to find out those compile errors and what modifications we need to make in vcl to achieve 1.1 compatibility with the OS X native code!
ed
Last edited by OPENSTEP on Fri Oct 10, 2003 12:14 am; edited 1 time in total
since gcc_select 3 uses gcc 3.1, which had some really dumb bugs. Any derivation of OOo 1.1 will require the Apple December 2002 Developer Tools (includes gcc 3.3) or later.
Next, it looks like there are more scripts to mark as executable The fixperms.sh script at the root level of the checkout does this for everything in 1.0.1, but we need to update that for 1.1 I guess.
And it looks like the 'nas' module's makefile got mis-patched, will have to correct that.
Thanks for the testing, and keep it up! We'll post some notes here when we get the fixes committed so you can try again.
I've committed a lot of small fixes to keep the build going, and I'm now in pyuno. I'm not yet to vcl, which I expect to fail miserably and require some real manual work, but its coming along nicely.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Oct 08, 2003 11:11 pm Post subject:
I also found an issue with the way I defined the modules that may cause "cvs update" in the root of your checkout to not recognize all the modules. If you try to "cvs update" and immediately see a bunch of lines starting with "?" (e.g. "? autodoc" may be one of the first) then you need to run a different command to do a full update:
Code:
ls | xargs -n 1 cvs update -d -P
I think I fixed the module definition and am checking right now to see if the problem goes away, but the fix would only apply for fresh checkouts and the above command is still needed for older ones.
which will pretty much do the same thing, provided you happen to have all the modules you need. If you don't, it won't pull down new ones, but if you've got everything it works just fine.
In other news, the Sablot patch is screwing up since I had to add -ObjC++ to CXXFLAGS. I think we had this problem before (it doesn't like a class def in arena.h) but I don't remeber what the fix was. Before enabling -ObjC++ I got all the way to the VCL, but of course now we have to start over with a clean build, since I think ObjC++ might change the ABI? Anyway, if nobody else gets there first, I'll try to check it out tongiht.
Also, if anyone is running a dual processor Mac, can you try to build with this?
cd instsetoo; build.pl --all -P 2
That will do a parallel build. I've noticed that with build.pl in parallel, I get hangs at odd places in the build, its never the same place twice. If anyone else can verify this behavior, we can work toward getting it fixed. Its a lot faster to do parallel builds.
Joined: Jun 07, 2003 Posts: 234 Location: near Cologne, Germany
Posted: Thu Oct 09, 2003 9:47 am Post subject: Next compile error
Hello,
here's the next compile error with "fresh" cvs-code and gcc 3.3:
../stlport/cctype:64: error: `toupper' not declared
../stlport/stl/debug/_debug.c: In static member function `static void
_STL::__stl_debug_engine<_Dummy>::_Message(const char*, ...) [with _Dummy =
bool]':
dll_main.cpp:147: instantiated from here
../stlport/stl/debug/_debug.c:246: error: `__args' undeclared (first use this
function)
../stlport/stl/debug/_debug.c:246: error: (Each undeclared identifier is
reported only once for each function it appears in.)
../stlport/stl/debug/_debug.c:263: error: `vfprintf' undeclared in namespace `
std'
make: *** [../lib/obj/GCC/ReleaseD/dll_main.o] Error 1
dmake: Error code 2, while making './unxmacxp.pro/misc/build/so_built_so_stlport'
---* TG_SLO.MK *---
ERROR: Error 65280 occurred while making /neooffice/stlport
dmake: Error code 1, while making 'build_all'
---* TG_SLO.MK *---
May be we should start using NeoOffice-Bugzilla to handle the compile errors now?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Oct 09, 2003 10:19 am Post subject: Re: Next compile error
schlesi wrote:
May be we should start using NeoOffice-Bugzilla to handle the compile errors now?
Could be interesting, but would it just be a single "build breakage" issue, or multiple ones? Thoughts?
I can confirm the Sablot breakage with ObjC++ and wil definitely look into it tonight. I actually don't recall having ObjC++ issues with Sablot before, since I'm pretty sure we threw the ObjC++ flag with the CoreGraphics migration. Looking through the CVS logs for the Sablot patch, the only apparent issues we had were the desissl script corruptions (it also appeared this was present in the move from 638C to STABLE1).
Joined: Jun 07, 2003 Posts: 234 Location: near Cologne, Germany
Posted: Thu Oct 09, 2003 12:28 pm Post subject:
May be we could handle compiling/building issues in one (this?) forum thread until the building is completely successful for the first time and after that, when compiling/building issues are exceptions, we use bugzilla?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Oct 10, 2003 12:21 am Post subject: sablot module now compiles
fa wrote:
In other news, the Sablot patch is screwing up since I had to add -ObjC++ to CXXFLAGS. I think we had this problem before (it doesn't like a class def in arena.h)
I found a workaround for the compile error in Sablot. I regenerated the patch and committed, so if you cvs update sablot it should be able to build with the ObjC++ flag now. I just passed sablot in my build and am continuing.
There were two problems in sablot. One was the compiler choking on a member function with a default parameter set to a sizeof, e.g.:
Code:
class foo {
public:
...
void * funnyhaha(long loser, int alignment = sizeof(void *));
...
};
The second was a constructor with a default initializer that contained a cast-away of constness. The class "loser" is the one that borked the compiler:
Code:
class ha {
public:
...
ha(char *lala, int blech);
...
};
class loser {
public:
loser(const char *suck, int ric_flair) : myha((char*)suck, ric_flair) {};
...
private:
ha myha;
...
};
Those seem to be a bit simplified as I didn't seem to have problems in little test cases. The only commonality I can think of is that both of them involved parentheses? Or perhaps typecasts in initializers and default values (isn't sizeof a size_t?)
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Oct 10, 2003 12:31 am Post subject: idlc build failure fixed
The next breakage was in the idlc module. I just committed a fix, so you should cvs update idlc as well.
This one is bizarre...(it's in idlc/inc/idlc/idlc/hxx for the curious). The exact line that used to give the error was a forward declaration:
Code:
class AstModule;
with the compiler complaining that "class" was used as a type but wasn't defined. Almost like the preprocessor chose the wrong language or something Inserting a bogus forward "struct" declaration in front of it caused the error to vanish and the whole module then compiled.
Something's fishy in denmark with this preprocessor...which is why I'm trying to keep documentation here on what was hosed in case others run into the same problems with ObjC++/gcc3.3.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Fri Oct 10, 2003 12:57 am Post subject:
Well, it broke b4 I went to bed. Latest error is in cppu. I'm not quite sure what the error is right now, but the initial error trace makes it seem like it's in STLport, perhaps in hash_map?
Code:
VEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRX645 -DBUILD_OS_APPLEOSX -DBUILD_OS_MAJOR=10 -DBUILD_OS_MINOR=2 -DBUILD_OS_REV=8 -DQUARTZ -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../unxmacxp.pro/slo/jobqueue.o /Volumes/abyss/neooffice-11-new/cppu/source/threadpool/jobqueue.cxx
In file included from /Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_vector.h:48,
from /Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_hashtable.h:34,
from /Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_hash_map.h:34,
from /Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/hash_map:27,
from /Volumes/abyss/neooffice-11-new/cppu/source/threadpool/threadpool.hxx:45,
from /Volumes/abyss/neooffice-11-new/cppu/source/threadpool/jobqueue.cxx:46:
/Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_uninitialized.h:51: error: parse error before `_InputIter'
/Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_uninitialized.h:62: error: parse error before `&' token
/Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_uninitialized.h: In function `_ForwardIter uninitialized_copy(_InputIter, _InputIter, _ForwardIter)':
/Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_uninitialized.h:79: error: parse error before `<' token
/Volumes/abyss/neooffice-11-new/solver/645/unxmacxp.pro/inc/stl/stl/_uninitialized.h:83: confused by earlier errors, bailing out
{standard input}:2:FATAL:.abort detected. Assembly stopping.
That would suck if STLport has issues...sigh. One for tomorrow night after the Rangers home opener
All times are GMT - 7 Hours Goto page 1, 2, 3, 4, 5, 6Next
Page 1 of 6
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
The fixperms.sh script at the root level of the checkout does this for everything in 1.0.1, but we need to update that for 1.1 I guess.
Inserting a bogus forward "struct" declaration in front of it caused the error to vanish and the whole module then compiled.
