Begin forwarded message: > > From: Casimiro de Almeida Barreto <[hidden email]> > Date: 10. April 2010 16:16:23 MESZ > To: The general-purpose Squeak developers list <[hidden email]> > Subject: [squeak-dev] This is still happening while building VM from inside Fedora > Reply-To: The general-purpose Squeak developers list <[hidden email]> > > Steps: > > * 1 svn squeak-vm sources > * 2 cd squeak-svn > * 3 mk build > * 4 cd build > * 5 ../platforms/unix/cmake/configure > * 6 make > > At end: > > [ 93%] Building C object > UUIDPlugin/CMakeFiles/UUIDPlugin.dir/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c.o > /home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c: > In function ‘MakeUUID’: > /home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c:17: > error: storage size of ‘uuid’ isn’t known > make[2]: ** > [UUIDPlugin/CMakeFiles/UUIDPlugin.dir/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c.o] > Erro 1 > make[1]: ** [UUIDPlugin/CMakeFiles/UUIDPlugin.dir/all] Erro 2 > make: ** [all] Erro 2 > [casimiro@localhost bld]$ bash > [casimiro@localhost bld]$ cd ../platforms/unix/plugins/UUIDPlugin > [casimiro@localhost UUIDPlugin]$ vi +17 sqUnixUUID.c > [casimiro@localhost UUIDPlugin]$ ls /usr/include/uuid > > It's possible to solve manually overriding settings uuid.h but it's not > nice & shouldn't be necessary > > Best regards, > > Casimiro > |
Thanks, Bert, I saw this. I don't have a Fedora to check on and probably won't have time to install one in the next couple of weeks. Sounds like a trivial problem though, maybe a tiny change in the headers from one version to another? I always build on a recent Ubuntu which tends to have recent versions (younger than six months) of everything. >> It's possible to solve manually overriding settings uuid.h but it's >> not >> nice & shouldn't be necessary What, PRECISELY, has to be done in/around uuid.h to solve this? Cheers, Ian |
I was hoping to have automatic update notifications from SqueakSource/VMMaker to the list, but no joy so this will have to do. I made an update to VMMaker to add some primitives to identify version level of the VM. This change is *not* required to support Squeak 4.1 release, and changes to platform code are required only if you want all of the primitives to work (i.e. everything still compiles regardless). Ian, I have attached updated platforms/unix/vm/config.cmake and platforms/unix/cmake/configure files that support the new #primitivePlatformSourceVersion primitive. - Dave Name: VMMaker-dtl.169 Author: dtl Time: 10 April 2010, 3:43:27.612 pm Ancestors: VMMaker-ar.168 VMMaker 4.0.3 Add version identification primitives - primitiveInterpreterSourceVersion answers the version of VMMaker that was used to generate the VM source code. This is a string like '4.0.3'. - primitivePlatformSourceVersion answers the Subversion version level if $PLATFORM_SOURCE_VERSION has been defined, or fails otherwise. This should be a string like '2172'. - primitiveVMVersion answers an identifier for the VM version (VMMaker plus Subversion) if $VM_VERSION is defined, or fails otherwise. For the Unix VMs, this is a string like '4.0.3-2172'. - primitiveImageFormatVersion answers an integer identifier for the image format. This is the number that is stored in the image file header to identify image fomat (32/64 bit word size, block closure support). Rename some code generation methods from #writeXXX to #emitXXX for consistency with other method naming. Fix VMMaker file list processing to ignore Subversion administrative files (previously only CVS files were ignored). patches-for-vmm.tgz (4K) Download Attachment |
In reply to this post by Ian Piumarta
Em 10-04-2010 16:54, Ian Piumarta escreveu: > > Thanks, Bert, I saw this. > > I don't have a Fedora to check on and probably won't have time to > install one in the next couple of weeks. Sounds like a trivial > problem though, maybe a tiny change in the headers from one version to > another? I always build on a recent Ubuntu which tends to have recent > versions (younger than six months) of everything. > >>> It's possible to solve manually overriding settings uuid.h but it's not >>> nice & shouldn't be necessary > > What, PRECISELY, has to be done in/around uuid.h to solve this? in line: #include <uuid.h> change to: #include <uuid/uuid.h> and compilation goes OK. > > Cheers, > Ian > > Cheers CdAB |
Free forum by Nabble | Edit this page |