Problems building rev 2181 on Linux

 
Hi,

 
Let me guess, you tried loading VMMaker directly from the repository  
rather than use the ConfigurationOf...?
All the issues mentioned below are Pharo-specific, and handled (ie.  
Methods are changed etc.) by the metacello configuration.
There's been some work to restore VmMaker to a fork-agnostic state,  
not finished yet though. Check the recent vm-dev archive for details.

Cheers,
Henry

Den 9. apr. 2010 kl. 21.19 skrev laurent laffont <[hidden email]
 >:

 
Oops, make that issue 2 and 3.

Den 9. apr. 2010 kl. 23.50 skrev Henrik Johansen <[hidden email]
 >:

> All the issues mentioned below are Pharo-specific, and handled (ie.  
> Methods are changed etc.) by the metacello configuration.

 
Yes, please use the ConfigurationOfVMMaker, and also notice the post do it method: fixVMMakerForPharo

I think that's the magic.

Cheers

Mariano

 
I've used ConfigurationOfVMMaker  1.2 but after I've updated VMMaker package only. trunk doesn't compile with VMMaker-dtl.157. Maybe it's time for version ConfigurationOfVMMaker 1.3 ?

 
On Sat, Apr 10, 2010 at 08:03:41AM +0200, laurent laffont wrote:
>  
> I've used ConfigurationOfVMMaker  1.2 but after I've updated VMMaker package
> only. trunk doesn't compile with VMMaker-dtl.157. Maybe it's time for
> version ConfigurationOfVMMaker 1.3 ?

In general, if you are building a VM with the latest version of platform
code from Subversion, then you would also want to use the latest version
of VMMaker from SqueakSource. I am not very familiar with Metacello
configurations, but I would say that it either needs an update to 1.3,
or better would be to just have Metacello always use the latest version.
Is there a way to do that?

Dave

 

Hi david

the problem with always loading the latest is that you end up having difficulty
to load a given version of the past. Here you have only a limited of source entities to sync
but as soon as you waht to have a couple of package it does not really scale.
This is why metacello is good like that we could in 3 years from now build again
a system for 1.0.
do you tag the svn with the version of VMMaker (or the inverse) so that at least we can trace it?

Stef

 
Stef,

On Apr 10, 2010, at 12:28 PM, stephane ducasse wrote:

> do you tag the svn with the version of VMMaker (or the inverse) so  
> that at least we can trace it?

The version numbering for Unix is X.Y.Z.V where X.Y.Z is the version  
of VMMaker and Z is the subversion revision of platforms/unix/
ChangeLog.  I always commit ChangeLog last when there is a set of  
changes, and I always use a log entry suggesting there might be a VM  
versioned after the revision created by that particular commit.

HTH.

Cheers,
Ian

 
On 4/10/2010 12:28 PM, stephane ducasse wrote:
> the problem with always loading the latest is that you end up having difficulty
> to load a given version of the past. Here you have only a limited of source entities to sync
> but as soon as you waht to have a couple of package it does not really scale.

That's why David said "in general". Yes, we're aware of that. It's why
we've always had file releases. If you want to rebuild precisely some
version of the VM you fetch the appropriate file release.

> This is why metacello is good like that we could in 3 years from now build again
> a system for 1.0.

Metacello does not help with that. What David was pointing out that if
people pull from head, then they need to do it consistently. Assuming
that a head version of SVN works with an old version that someone stuck
into Metacello is futile.

Cheers,
   - Andreas

CONTENTS DELETED

Yes!

On Apr 11, 2010, at 10:31 AM, Hilaire Fernandes wrote:

 
Again issues compiling in Fedora.

1) To compile Balloon3D it is necessary to include -lGL directive during
linking phase
2) To compile MIDI plugin it is necessary to include -lkmid directive
during linking phase

Although:

I was not able to find suitable libraries to link against
destroyManualSurface, primitiveCreateManualSurface createManualSurface
primitiveSetManualSurfacePointer and debugf

[casimiro@localhost bld]$ gcc -g -O2 -fomit-frame-pointer -DLSB_FIRST=1
-Wl,--hash-style=sysv -o squeak disabledPlugins.o version.o
-Wl,--export-dynamic  vm/vm.a ADPCMCodecPlugin/ADPCMCodecPlugin.a
AsynchFilePlugin/AsynchFilePlugin.a
B3DAcceleratorPlugin/B3DAcceleratorPlugin.a Squeak3D/Squeak3D.a
BMPReadWriterPlugin/BMPReadWriterPlugin.a B2DPlugin/B2DPlugin.a
BitBltPlugin/BitBltPlugin.a CroquetPlugin/CroquetPlugin.a
DSAPrims/DSAPrims.a ZipPlugin/ZipPlugin.a DropPlugin/DropPlugin.a
SqueakFFIPrims/SqueakFFIPrims.a FFTPlugin/FFTPlugin.a
FileCopyPlugin/FileCopyPlugin.a FilePlugin/FilePlugin.a
FloatArrayPlugin/FloatArrayPlugin.a FloatMathPlugin/FloatMathPlugin.a
GeniePlugin/GeniePlugin.a HostWindowPlugin/HostWindowPlugin.a
JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.a
JPEGReaderPlugin/JPEGReaderPlugin.a
JoystickTabletPlugin/JoystickTabletPlugin.a Klatt/Klatt.a
LargeIntegers/LargeIntegers.a LocalePlugin/LocalePlugin.a
MIDIPlugin/MIDIPlugin.a Matrix2x3Plugin/Matrix2x3Plugin.a
MiscPrimitivePlugin/MiscPrimitivePlugin.a Mpeg3Plugin/Mpeg3Plugin.a
RePlugin/RePlugin.a SecurityPlugin/SecurityPlugin.a
SerialPlugin/SerialPlugin.a SocketPlugin/SocketPlugin.a
SoundCodecPrims/SoundCodecPrims.a
SoundGenerationPlugin/SoundGenerationPlugin.a SoundPlugin/SoundPlugin.a
StarSqueakPlugin/StarSqueakPlugin.a SurfacePlugin/SurfacePlugin.a -lutil
-ldl -lGL -lkmid -lm -lnsl vm/vm.a -Wl,--rpath -Wl,/usr/local/lib
SqueakFFIPrims/SqueakFFIPrims.a(SqueakFFIPrims.o): In function
`primitiveDestroyManualSurface':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/src/vm/intplugins/SqueakFFIPrims/SqueakFFIPrims.c:2434:
undefined reference to `destroyManualSurface'
SqueakFFIPrims/SqueakFFIPrims.a(SqueakFFIPrims.o): In function
`primitiveCreateManualSurface':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/src/vm/intplugins/SqueakFFIPrims/SqueakFFIPrims.c:2411:
undefined reference to `createManualSurface'
SqueakFFIPrims/SqueakFFIPrims.a(SqueakFFIPrims.o): In function
`primitiveSetManualSurfacePointer':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/src/vm/intplugins/SqueakFFIPrims/SqueakFFIPrims.c:2818:
undefined reference to `setManualSurfacePointer'
SqueakFFIPrims/SqueakFFIPrims.a(SqueakFFIPrims.o): In function
`initialiseModule':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/src/vm/intplugins/SqueakFFIPrims/SqueakFFIPrims.c:2075:
undefined reference to `initSurfacePluginFunctionPointers'
MIDIPlugin/MIDIPlugin.a(sqUnixMIDI.o): In function `performMIDICmd':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc:504:
undefined reference to `debugf'
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc:499:
undefined reference to `debugf'
MIDIPlugin/MIDIPlugin.a(sqUnixMIDI.o): In function `midiShutdown':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc:486:
undefined reference to `debugf'
MIDIPlugin/MIDIPlugin.a(sqUnixMIDI.o): In function `sqMIDIPortReadInto':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc:409:
undefined reference to `debugf'
MIDIPlugin/MIDIPlugin.a(sqUnixMIDI.o): In function `sqMIDIGetPortCount':
/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc:199:
undefined reference to `debugf'
MIDIPlugin/MIDIPlugin.a(sqUnixMIDI.o):/home/casimiro/Softwares/squeak/squeak-svn/platforms/unix/plugins/MIDIPlugin/sqUnixMIDIALSA.inc:187:
more undefined references to `debugf' follow
collect2: ld returned 1 exit status

 

Laurent Laffont

 
On Apr 11, 2010, at 10:13 AM, Casimiro de Almeida Barreto wrote:

> I was not able to find suitable libraries to link against  
> destroyManualSurface, primitiveCreateManualSurface  
> createManualSurface primitiveSetManualSurfacePointer

These are undefined in my build too, and are not supplied by any other  
plugin nor by the statically-linked VM.  Does anyone know where these  
are supposed to come from?

> debugf

Try adding

#include "debug.h"

to the top of sqUnixMIDIALSA.inc.

Thanks!
Ian

 
On Apr 11, 2010, at 11:44 AM, Ian Piumarta wrote:

>> I was not able to find suitable libraries to link against  
>> destroyManualSurface, primitiveCreateManualSurface  
>> createManualSurface primitiveSetManualSurfacePointer
>
> These are undefined in my build too, and are not supplied by any  
> other plugin nor by the statically-linked VM.  Does anyone know  
> where these are supposed to come from?

More precisely: the primitive* versions are there but refer to the  
destroy* and create* functions which are nowhere to be found.

 
sqManualSurface.c

On 2010-04-11, at 11:44 AM, Ian Piumarta wrote:
--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================

 
On 4/11/2010 11:44 AM, Ian Piumarta wrote:
> On Apr 11, 2010, at 10:13 AM, Casimiro de Almeida Barreto wrote:
>
>> I was not able to find suitable libraries to link against
>> destroyManualSurface, primitiveCreateManualSurface createManualSurface
>> primitiveSetManualSurfacePointer
>
> These are undefined in my build too, and are not supplied by any other
> plugin nor by the statically-linked VM. Does anyone know where these are
> supposed to come from?

platforms/Cross/plugins/SqueakFFIPrims/sqManualSurface.c

Cheers,
   - Andreas

 

 
On Sun, Apr 11, 2010 at 08:24:06PM +0200, laurent laffont wrote:
Laurent,

I would say yes, you should check it in. This will give you a configuration
that matches the platforms sources that are being used in the latest
round of platform updates.

Please set the VMMaker package version to 169 (not 168), as this
will bring in the latest changes, and is compatible with the most
up to date Subversion sources.

I would also recommend that you add a comment either in the code
or in the Monticello check-in note, and mention that this configuration
is intended to work with Subversion revision level 2188 (plus or minus
a little bit). That will give people an indication of what platform
version to use a few years from now.

As Andreas mentioned, you cannot reliably rebuild a VM by referring
only to the Metacello configuration, but that is a separate issue
and you are right to make this update.

Dave