[Vm-dev] Re: Uploaded squeak-vm 3.11.3

[Levente Uzonyi]

On Wed, 27 Jan 2010, David T. Lewis wrote:

>
> On Wed, Jan 27, 2010 at 09:41:26AM -0800, Bert Freudenberg wrote:
>>
>> On 26.01.2010, at 16:54, David T. Lewis wrote:
>>>
>>> VMMaker is also designed to be scriptable (i.e. controllable independent
>>> of the VMMakerTool interactive tool). See Tim's class comment for details.
>>
>> Maybe I didn't make myself clear :)
>
> Sorry, my mistake.
>
>> I know VMMaker is "scriptable" inside Squeak. What the OP was referring
>> to was putting that translation step into a makefile. Which would need
>> a tightly controlled setup of vm, image, and packages to work reliably.
>> Which IMHO is too much trouble right now.
>
> Agreed. On a related note, we seem to be running into problems with people
> taking the existing generated sources from platforms/unix/src and doing
> a configure/make on their 64 bit Linux box, resulting in a broken VM.
> Their expectation that this should work is perfectly reasonable, but the
> fact is that it does not; we still have too many broken plugins on 64 bits.
>
> I'm not sure how best to prevent this problem, although possibly just
> adding -m32 to the CFLAGS as a default would help (I'm not sure if this
> is safe to do for all the various unices).

I had an issue earlier with -m32. I had to tell the linker that the 
object files are for 32 bit otherwise the build process stopped with an 
error message. Some plugins had their own flags which couldn't be 
overriden by CFLAGS (FloatMathPlugin for example, don't know if it still 
uses -O only). My (quick-and-dirty) workaround was to pass the compiler 
arguments in CC and leave CFLAGS empty. (CC="gcc -m32 ..." CFLAGS="")


Levente

>
>> Maybe we just need to come up with a satisfying answer to the question
>> raised in the bug report? It seems as if just describing how this was
>> generated might be sufficient.
>
> That would certainly be the simplest solution, and if it turns out not
> to be good enough, it would at least make it easier to identify what
> *would* be sufficient.
>
> Dave
>
>