IAN IS EVIL.

Don't let anyone tell you otherwise...

Here's all the proof you need:

Several years ago I complained to Ian that I couldn't build squeak with
the Croquet-crucial B3D plugins. I eventually found that the problem
went away with the item $(X_LIBS) appended to make.prg.in.

He gave me a patronizing explaination of why that was stupid. He said he
would correct the problem.

I have continued to experience this problem time and time again, each
time I complain to him that it is still broken.

Now that many more months have passed, I, and my imperfect memory,
forgot about the issue. Only when I remembered the problem I thought to
re-apply my time-tested patch to get a successful build. GAAAAAAAHHHH!!!!

Anyway, now that I'm back in the VM hacking game, here's my idea...

There have been several suggestions for incompatible changes to the VM.
Because it is still desirable to support older images (notably my
workhorse 3.7 image with all my stuff in it...) I have come up with the
idea of the "helper image"... The "helper image" is basically a patch
that is applied to the main image at load time that includes the stuff
the older image needs. (I'm planning an all out war on special objects,
especially "Display").

--
Friends don't let friends use GCC 3.4.4
GCC 3.3.6 produces code that's twice as fast on x86!

http://users.rcn.com/alangrimes/

Alan,

Your choice of subject line is offending and I am the moderator/admin of
this list.
You or anyone else are entitled to opinions about how the work on the VM
is conducted - but keep the tone civilized, please.

regards, Göran

On Oct 23, 2005, at 12:00 PM, Alan Grimes wrote:

> Don't let anyone tell you otherwise...

I'm kind of touched that it took you so long to notice.

> Several years ago I complained to Ian that I couldn't build squeak  
> with
> the Croquet-crucial B3D plugins. I eventually found that the problem
> went away with the item $(X_LIBS) appended to make.prg.in.

I still think this will prevent the executable from running when it's  
installed on a machine that has no X11 libraries.  Maybe GNU/Linux is  
immune to this, but not architectures where I know for certain that  
the dynamic loader eagerly resolves transitive dependencies  
regardless of needing to resolve any symbols within them.  (The XLIBS  
dependencies belong on vm-dpy-x11.so, not on the VM itself.)  
However, evil intentions may have caused me to exclude some  
configurations from building properly -- including internal  
(statically-linked) B3D support in the VM.

I have flagged your message as important and put it in the bugs  
queue.  Assuming I can reproduce the problem I will fix it.  If I  
can't reproduce the problem then I will at least figure out a way for  
you to tell configure to add the dependencies you need to the link  
command.

Ian