-> generate all. -> go to src/vm, unstuff SqueakVMForCarbon.pbproj.sit -> click on SqueakVMForCarbon.pbproj, Projectbuilder starts. -> select the build-target (OPTtimized Vm, not Debug) -> Now have a look at the files and resources that are listed in the left pane: de-select all red-coded ones (they are not there).

So which ones are missing?

You'l get two errors in LargeIntergers, simply delete the "assert" funtion and prototype. (it's not used)

Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.

On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:

...

...

-> Now have a look at the files and resources that are listed in the left pane: de-select all red-coded ones (they are not there).

So which ones are missing?

The resources are not there (resources.sit is corrupted). Then I did not file in the changesets for UUID-Plugin and InternetConfig. But I found those and now the only source file missing is "sqGnu.h".

Ah if you startup stuffit expander and select the resource.sit. Does it complain it's corrupt? Maybe I need to make it as binhex to make cvs happy.

At 12:06 AM +0100 12/23/01, Marcus Denker wrote:

The real problem is that you need to customize the project (add some files, remove some files) if you don't build the exact same modules as John. This is annoying. I'd like to just type "make" or push some button. But there seems to be no possiblility to use a script to build the "Makefile" used by the Projectbuilder. That's bad.

Mmm if you look inside the SqueakVMForCarbon.pbproj folder/bundle you'll see a project.pbxproj file. That is an text file. Now it has fun stuff like

08773EF700C6A1C4C0A80109 = { isa = PBXFileReference; path = sqMacWindow.c; refType = 4; };

Then of course the key for the file is used in a few other places.

Bet once could autogenerate the file with a little Squeak Code. Mmm I was hoping that key was a UUID but a quick check shows a current UUID is squeak -> an UUID('f7d9637b-f76e-11d5-bd5b-00306540a296') or

[otter:~] johnmci% uuidgen 58674EBA-F76F-11D5-AC9E-00306540A296

Ya, my airport card has 003065110e6b as the address so neither match the ending. But I'm wondering how magical that number needs to be. Maybe there is a doc somewhere...

Hi!

--- John M McIntosh johnmci@smalltalkconsulting.com wrote: [SNIP]

Ah if you startup stuffit expander and select the resource.sit. Does it complain it's corrupt? Maybe I need to make it as binhex to make cvs happy.

Eh? If it is a binary file - why don't you check it in binary? That tells CVS to "stay out of it" and not expand keywords or convert lineendings.

regards, G�ran

===== G�ran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek

__________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

At 7:10 AM +0100 12/24/01, Stephan Rudlof wrote:

Marcus Denker wrote:

...

On Fri, Dec 21, 2001 at 01:14:47PM -0800, John M McIntosh wrote:

...

...

...

Ah, could you submit a change set for that I must have changed that a few months ago. The problem is assert is also defined in the mac bsd headers somewhere. The assert should really be changes to SqueakAssert or something versus being deleted.

Ok.

The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.

I just want to have an assert function, which does exactly what you expect from such a function.

Well in the bsd <assert.h> we have #define assert(expression) \ ((void) ((expression) ? 0 : __assert (#expression, __FILE__, __LINE__)))

then you do static int assert(int aBool) { /* missing DebugCode */; }

Then the GNU compiler gets grumpy.

Note that assert is also used in b3dAlloc.c which is one of the places the #include <assert.h> is invoked to pickup the BSD definition.

I'm assuming you could revert to use #include <assert.h> then use assert as defined for BSD assert versus your own version. Mmm right now it appears your assert doesn't do anything? Should it?

Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here.

Looking deeper into this it seems that assert.h is included by Apple's core foundation header. This header is gotten to by sqConfig.h which on the mac under OS-X includes "/Developer/Headers/FlatCarbon/MacTypes.h" which

includes "/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h" which includes "/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h"

which at some point includes assert.h found at "/usr/include/gcc/darwin/2.95.2/g++/../assert.h"

I just wanted (I'm not really sure, see below) to have the most common ANSI-C assert. If your BSD assert (what means BSD here?) is such a thing, OK.

Below is the man page for the BSD (aka FreeBSD being the reference edition for OS-X) assert, but it seems the GNU assert is used here which overrides the platform definition for consistency according to notes on newsgroups from the 1990. The GNU assert.h is defined below (at least the interesting parts).

Thus either the assert used by LargeInteger.c uses the GNU assert, or platform assert, or it needs another name because it's not really assert.

GNU assert.h <partial>

extern void __eprintf () __attribute__ ((noreturn)); /* Defined in libgcc.a */

#define assert(expression) \ ((void) ((expression) ? 0 : __assert (expression, __FILE__, __LINE__)))

#define __assert(expression, file, lineno) \ (__eprintf ("%s:%u: failed assertion `%s'\n", \ file, lineno, "expression"), 0)

libgcc2.c has <partial>

/* This is used by the `assert' macro. */ extern void __eprintf (const char *, const char *, unsigned int, const char *) __attribute__ ((__noreturn__));

void __eprintf (const char *string, const char *expression, unsigned int line, const char *filename) { fprintf (stderr, string, expression, line, filename); fflush (stderr); abort (); }

BSD assert man page

ASSERT(3) System Programmer's Manual ASSERT(3)

NAME assert - expression verification macro

SYNOPSIS #include <assert.h>

assert(expression)

DESCRIPTION The assert() macro tests the given expression and if it is false, the calling process is terminated. A diagnostic message is written to stderr and the abort(3) function is called, effectively terminating the program.

If expression is true, the assert() macro does nothing.

The assert() macro may be removed at compile time with the cc(1) option -DNDEBUG.

DIAGNOSTICS The following diagnostic message is written to stderr if expression is false:

"assertion "%s" failed: file "%s", line %d\n", \ "expression", __FILE__, __LINE__);

SEE ALSO cc(1), abort(3)

STANDARDS The assert() macro conforms to ANSI C3.159-1989 (``ANSI C'').

HISTORY A assert macro appeared in Version 6 AT&T UNIX.

Added support to compile under os-x as a bundle. This requires a change to how files names are resolved when open the file

'From Squeak3.2alpha of 1 November 2001 [latest update: #4599] on 27 December 2001 at 3:41:11 pm'!

!Mpeg3Plugin methodsFor: 'primitives' stamp: 'JMM 12/27/2001 15:39'! primitiveMPEG3CheckSig: path | result sz |

"int mpeg3_check_sig(char *path)" self var: #storage declareC: 'char storage[1024] '. self primitive: 'primitiveMPEG3CheckSig' parameters: #(String). sz _ interpreterProxy byteSizeOf: path cPtrAsOop. self cCode: 'sqFilenameFromStringOpen(storage, path, sz)'. self cCode: 'result = mpeg3_check_sig(storage)'. ^result asOop: Boolean ! !

!Mpeg3Plugin methodsFor: 'primitives' stamp: 'JMM 12/27/2001 15:40'! primitiveMPEG3Open: path | mpeg3Oop index sz storage |

"mpeg3_t* mpeg3_open(char *path)" self var: #index declareC: 'mpeg3_t ** index'. self var: #storage declareC: 'char storage[1024]'. self primitive: 'primitiveMPEG3Open' parameters: #(String). sz _ interpreterProxy byteSizeOf: path cPtrAsOop. self cCode: 'sqFilenameFromStringOpen(storage, path, sz)'. mpeg3Oop _ interpreterProxy instantiateClass: interpreterProxy classByteArray indexableSize: 4. index _ self cCoerce: (interpreterProxy firstIndexableField: mpeg3Oop) to: 'mpeg3_t **'. self cCode: '*index = mpeg3_open(storage); makeFileEntry(*index)'. ^mpeg3Oop. ! !

John M McIntosh wrote:

...

John M McIntosh wrote:

...

...

Not for the Linux version! *Where* happens this '#include <assert.h>' leading to this clash? There is no such include here.

Looking deeper into this it seems that assert.h is included by Apple's core foundation header. This header is gotten to by sqConfig.h which on the mac under OS-X includes "/Developer/Headers/FlatCarbon/MacTypes.h" which

includes

"/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h" which includes

"/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h"

which at some point includes assert.h found at "/usr/include/gcc/darwin/2.95.2/g++/../assert.h"

What about just #undef assert (I think without braces) just after the #include "/Developer/Headers/FlatCarbon/MacTypes.h" in sqConfig.h? This should allow the inclusion of headers potentially using 'assert()'s, but removes its definition for the Squeak sources. Have you tried this approach?

Well we could but I think the question then is are we using assert as we know a unix assert, or are we using some other specialized sqAssert. I think overriding the unix assert could be confusing to some people.

That's a point.

Also you then get into interesting games here to ensure our assert is used versus the unix assert.

This shouldn't be a problem: just #undef it if necessary (#undef'ing at the begin of each - automatically generated - plugin should be sufficient; remark: so far - until your problem for *one* specific platform - there wasn't any assert problem).

Right now you have an assert in LargeIntegers.c but that's different than the one found in other locations in the source code.

Which source code? The ST #assert: throws an exception and therefore halts the program, what is quiet similar to my assert (I admit that the ST one is not as radical).

I don't want to ride the horse to death (correct?). If you and others are lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST and/or Swiki docu), that it is *forbidden* to use an assert() function like the ST #assert: in Slang, since it would conflict with the Unix one (after C code generation). Otherwise others could easily walk into the same trap (mostly it would work with their platform, but not with all).

Is this a compromise?

Greetings,

Stephan

--

=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

On Wednesday, January 2, 2002, at 02:11 AM, John M McIntosh wrote:

LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]

Well, even as a compromise, this ignores that the code, as written, is broken! I suggest eliminating it altogether as used here. Because of the

#self cCode:inSmalltalk

message, this method will not be inlined to the caller, even though the #debugCode inlines the generated code of #assert: to blank! This is what appears to be happening in the generated code for LargeIntegerPlugin.

Thus, the generated code for the production version contains calls like:

assert(limit < lenFrom);

which are evaluated for an empty procedure, I don't know how many optimizing compilers are smart enough to pick this one up, but with less than careful optimiztion, this means that all your assertion expressions are evaluated.

This is particularly egregious for LargeIntegersPlugin, since that code tends to live inside many inner loops for computation-intensive work. The microseconds wasted for such computations -- which are unnecessary if this were done differently -- add up.

Thus, in addition to the decidedly annoying problems with some important platform development systems and the like, this structure is also highly inefficient, because

John M McIntosh wrote:

At 4:01 AM +0100 12/28/01, Stephan Rudlof wrote:

...

Which source code? The ST #assert: throws an exception and therefore halts the program, what is quiet similar to my assert (I admit that the ST one is not as radical).

I don't want to ride the horse to death (correct?). If you and others are lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST and/or Swiki docu), that it is *forbidden* to use an assert() function like the ST #assert: in Slang, since it would conflict with the Unix one (after C code generation). Otherwise others could easily walk into the same trap (mostly it would work with their platform, but not with all).

Is this a compromise?

Yes, it's quite workable. Now if someone wants to resubmit a change set to clean this up, that would be great.

Note the usages below.

It would seem that BalloonEngineSimulation>>assert: should really use the Object>>assert: which means some changes because one expects a block, the other a boolean. Which is correct is a question? SUnit expects a boolean, perhaps our usage on Object as a block should change to avoid confusion.

Perhaps a better name for the plugin assert is sqPluginAssert? I'm also assuming this could be folded into InterpreterPlugin? Printing a message, is ok, but I wonder if we want to also print a stack trace too before doing the exit(1), or is that a primitiveFail and return we want (I suspect so?) This implies doing a return will be ok, or do we need sqPluginAssertExit & sqPluginAssertReturn?

TestCase>>assert: aBoolean aBoolean ifFalse: [self signalFailure: 'Assertion failed']

Object>>assert: aBlock "Throw an assertion error if aBlock does not evaluates to true."

    aBlock value ifFalse: [AssertionFailure signal: 'Assertion failed']

BalloonEngineSimulation>>assert: bool bool ifFalse:[^self error:'Assertion failed'].

LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]

My last [ENH] suggestion was to kick this >>assert: and to use a modified one: TestInterpreterPlugin>> sqAssert: aBool self debugCode: [aBool ifFalse: [self error: 'Assertion failed!']. ^ aBool]

This eliminates any assert() calls in production code and results in an exit() call (see error() in interp.c) with call stack printing for debug code.

See TIPlugin-cleanup-sr.1.cs.gz in mail subjected [ENH] TestInterpreterPlugin-cleanup-sr .

For me this is a simple variant for developer code and *documentation* purposes (>>sqAssert:'s say something about the semantics of the code!). The question remains if it makes sense to provide a more complicated variant with >>primitiveFail semantics. For me the simple one is at least a good start.

Greetings,

Stephan

--

=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

It sounds to me that there are several varieties of 'assert()' that exist in C-land and a variety of ways of getting them into an executable. This suggests to me that we should sidstep the problem by using our own name (is there anything wrong with #sqAssert: ?) and defining it to sensibly suit the needs of the vm. I see from a cursory search on the web that there is at least a dichotomy between assert()s that simply write the line & function name out to a log and those that then abort you program. I'm not sure either is adequate for real uses; wouldn't it be more useful to have a flag for a fatal problem so you can choose whether you need to log or die?

tim

Stephan Rudlof wrote:

#sqAssert: is a workaround: We already have this nice ST #assert:, and I'd be happy to be allowed to use the same name for a C assert() with a related semantics. And it annoys me to be forced to avoid this name just since there is some platform specific include problem.

Well I have some sympathy with the attitude but I rather suspect it would be lot simpler to roll over and just put up with having a different name. Think of it as jujitsu programming, skilfully avoiding a problem by moving slickly to one side of the monster.

This gives me an idea: we already have #primitiveFailed and could possibly define #assert: to use it instead of a hardcore abort() (together with some logging stating than an assert has failed). What do you think about this?

Yes we could certainly do something like that. I'd suggest a form of assert that can cleanly return a defined failure notification as well as one that can do the "argh! I'm dead!" sort of failure.

I think a simple primitiveFail is a bit lacking in information content. It is a simple matter to extend it to set a defined temp variable in the calling context to some object that provides more info. We used a form of this for the Interval project and it allows one to quickly owrk out why the prim failed. BitBLT could use it to specify _which_ coordinate was innapropriate, or which Form was invalid. A file prim could return a sensible reason for why your attempt to open a file failed (file not there? permissions? bad breath?).

It has been argued that one could do this by having a get-last-error prim and copy the errno() idea form unix. This is a poor idea for two reasons:- copying a dumb idea from a daft OS is not sensible and unless you propose to put some form of critical block around every prim call you could not trust that the result of a separate prim has anything to do with the one that failed.

The code changes to enable this are very simple but (unless one wants to put tedious guard code around the place) it does have something of a Heaviside function about it - an image expecting it can run on an older vm, but an updated vm would crash an older image. It might be a good thing to include in the list of image-format-breaking changes alongside new compiled method format, blocks etc etc.

tim

Marcus Denker wrote:

On Mon, Dec 24, 2001 at 07:10:37AM +0100, Stephan Rudlof wrote:

...

The current workaround is to have >>sqAssert: in the LargeIntergersPlugin. I'm not happy with this.

I just want to have an assert function, which does exactly what you expect from such a function. The semantics should be the same for as ST #assert: as C 'assert()'. And now there comes one compile problem and we have to change code on the ST side. Furthermore I have to follow the rule: 'Don't use #assert: in plugin code!'. (And when comes the next function name, which I cannot use?)

....

...

Possible solutions:

• If it is a macro defined elsewhere, you are probably able to #undef it in

your special platform specific code.

• On the other side: what about '#include <assert.h>' as standard for all

plugins? Then we don't have to define such a function for plugins in ST. And the #assert: in ST matches the C 'assert()' well in semantics.

Or: We could chane the SLANG Codegenerator to use a prefix (like "sq_") for every function it generates... (instead of generationg a function "assert()" it would generate "sq_assert()" for the "assert:" method) this would solve this kind of problem once and for all.

Good idea: *all* 'private' C functions of InterpreterPlugin subclasses could have this prefix. We shouldn't use it for exported functions though, they already have the module prefix, which should be sufficient.

We are continuing to emulate C++ namespaces here...

Wait: why not using a C++ compiler with namespace Squeak instead? ;-)

Greetings,

Stephan

Marcus

-- Marcus Denker marcus@ira.uka.de

On Fri, Dec 21, 2001 at 09:58:34PM -0800, Tim Rowledge wrote:

...

Plugins not build: FileCopyPlugin IntegerPokerPlugin

Was this because of a problem, or your choice? It built ok on linux this afternoon.

They weren't included in the Projectbuilders Makefile... I just tried, IntegerPokerPlugin is no problem, but FileCopyPlugin needs an additional library (and I havn't yet looked a t building that on OS X).

Oh, and you _have_ to have the LargeFile-jmm.cs installed. This is potentially a problem in our vm maintenance process I suppose; how can we make sure that things are kept in step? Maybe this would be helped by SqCVS in some manner since we could make sure to fetch vm related changesets along with the C code?

Don't know if you really need them... I think they will be in the update stream soon.

The real problem is that you need to customize the project (add some files, remove some files) if you don't build the exact same modules as John. This is annoying. I'd like to just type "make" or push some button. But there seems to be no possiblility to use a script to build the "Makefile" used by the Projectbuilder. That's bad.

Marcus

I just tried to make a Mac VM from the tree from SF and a latest 3.1 +VMMaker image. It does have the 64bit access doohickeys and the image was used to make a working linux VM yesterday.

I used the vm/SqueakPro5.xml as a project to import into codeworrier. I had to edit the access path/user paths/project to make it {Project}:src in order to get the compiler to llok at the files in src/vm/... instead of platforms/vm/... etc. Breathtakingly dumb thing for codeworrier to do, but it seems to be really good at that sort of thing.

I got 307 red-hand errors. Couldn't find project file "InternetConfigPlugin.c" Identifier 'mkdir(const char*,...) redeclared was declared as : int (const char*, int) now declared as: int (const char*,...) sqMacDirectory.c line 23 Couldn't find project file "sqMacInternetConfiguration.c" and 300 plus complaints about the sqMAcOpenGLInfo.c file not being able to open GL/gl.h

Suggestions for how to get past this list of problems welcomed. I probably did something wrong by changing the {Project} thingy, but it appeared to be the only way forward!

tim

I'm trying to get a VM build environment going on a Linux machine from the CVS platforms tree and VMMaker. It looks like the configure and make scripts are not quite happy with this new directory structure. I try to run platforms/unix/misc/configure, but it's not happy. Am I missing something, or are things not quite there yet?

Thanks, Stephen

"David T. Lewis" lewis@mail.msen.com is widely believed to have written:

On Thu, Dec 27, 2001 at 08:21:17AM -0500, Stephen Pair wrote:

...

I'm trying to get a VM build environment going on a Linux machine from the CVS platforms tree and VMMaker. It looks like the configure and make scripts are not quite happy with this new directory structure. I try to run platforms/unix/misc/configure, but it's not happy. Am I missing something, or are things not quite there yet?

You're not missing anything. The good news it that it will build fine, except for the MPEG plugin; just ignore the warnings. You should consider the CVS repository to be an unauthorised hacker's copy of the master source, which belongs to Ian. Personally, I prefer to use the unauthorized hack, but don't be surprised if there are some problems with it.

Unauthorised ? In an open source wordd? Hmm, not sure that concept really applies. Anyway, the code in a few files needed altering to allow it to work with any/all plugins external; a diff between version would show what they are and how minor. Mostly small bugs that would require plugins to be internal in order for the vm to link successfully (I seem to remember an explicit init of the serial port for example, which the serial plugin handles if it is ever loaded)

The MPEG plugin needs some work in the makefile stuff - Lex originally provided an altered 'mkfrags' file that apparently makes it work, but I haven't had the time or reason to try to integrate it with the slightly hacked makefiles needd for the VMMaker system. I think the new JPEG plugin needs a tiny amount of rework as well, and I hope to get to it sometime. Aside from that, it really should be a case of

get image (up to 4478 currently tested by me) load VMMAker VMMakerTool openInWorld choose your poisons (which plugins are internal/external/ignored) pres the go button wait . . . chmod a+x src/con* src/ac* src/in* src/lt* src/util/* (to make stuff executable - see other emails about the problems of copying files and losing vital info in the process) mkdir build cd build ../src/configure make cp squeak .libs {my destination}

done!

Once you have done this you should find you have a 'FileCopyPlugin' which _ought_ to do the file copying properly next time and obviate the need for the permissions changing. We really need to improve the file system code.

A volunteer to discombobulate the Makefile.in for the CVS tree would no doubt be gratefully accepted.

I'm certain the makefiles stuff needs tidying up. I commented every change I made with 'tpr' - or at least tried to. An expert can probably make it much neater. Please do so....

Tim, did I get that about right?

Pretty much.

Building on a Mac ought to be similar, but Apple seem to delight in making programming difficult. I know it _can_ be done because John has been building the relese MAc VMs with it since goodness knows when. Windows is not something I can test personally since I haven't used a 'doze machine in five years or maybe more. Craig was able to get VMMAker running in about an hour a few months ago and the results of that are in the SF platform tree.

tim

On Fri, Dec 28, 2001 at 10:48:47AM -0500, Joshua 'Schwa' Gargus wrote:

The other thing that might happen is that typing "make" appears to run normally up until the following output:

copying last section of file mv gnuify.out gnu-interp.c gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -DHAVE_CONFIG_H -DUNIX -DSQ_LIBDIR="/usr/local/lib/squeak/3.1a-4164" -I. -I../src/vm -c gnu-interp.c gnu-interp.c:1234: conflicting types for `readImageFromFileHeapSizeStartingAt' ../src/vm/sq.h:309: previous declaration of `readImageFromFileHeapSizeStartingAt' make: *** [gnu-interp.o] Error 1

I hacked around this by changing the type in sq.h from offset_t to int. This let me get as far as:

ar -rc squeak.a.tmp sqNamedPrims.o sqUnixExternalPrims.o sqUnixMozilla.o sqVirtualMachine.o sqXWindow.o zipio.o zlib.o gnu-interp.o sqUnixVersion.o mv squeak.a.tmp squeak.a /bin/sh ./libtool --mode=link gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -avoid-version -export-dynamic -R/usr/local/lib/squeak/3.1a-4164 -o squeak squeak.a -lXext -lX11 -lm -ldl -lnsl -L/usr/X11R6/lib mkdir .libs gcc -I/usr/X11R6/include -g -O2 -fomit-frame-pointer -DLSB_FIRST=1 -funroll-loops -o squeak squeak.a -lXext -lX11 -lm -ldl -lnsl -L/usr/X11R6/lib -Wl,--export-dynamic -Wl,--rpath -Wl,/usr/local/lib/squeak/3.1a-4164 -Wl,--rpath -Wl,/usr/local/lib/squeak/3.1a-4164 squeak.a(sqVirtualMachine.o): In function `sqGetInterpreterProxy': /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:306: undefined reference to `positive64BitIntegerFor' /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:307: undefined reference to `positive64BitValueOf' /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:308: undefined reference to `signed64BitIntegerFor' /home/schwa/squeak.old/vm/vmmaker3/build/../src/vm/sqVirtualMachine.c:309: undefined reference to `signed64BitValueOf' collect2: ld returned 1 exit status make: *** [squeak] Error 1

There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?

Thanks, Joshua

This is a more reasonable error, but an error nonetheless. I have a hunch that the first behavior might be avoided by using VMMaker with a properly compiled FilePlugin. However, to do that, I have to avoid the second error.

Help?

Thanks, Joshua

...

cp squeak .libs {my destination}

done!

On Fri, Dec 28, 2001 at 10:45:23AM -0800, Tim Rowledge wrote:

Joshua 'Schwa' Gargus wrote:

...

There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?

Yup, you need the largefiles changes that define the 64bit routines and would fix the off_t error for you. I forgot to call out that particular problem, sorry!

No problem. I'm ecstatic at having successfully used VMMaker, and am looking forward to playing with my own plugins, now that it's so convenient. Thank you!

One more hack was necessary to successfully compile: I added #define sqFilenameFromStringOpen(dst, src, num) sqFilenameFromString(dst, src, num) to sqPlatformSpecific.h in order to get the FilePlugin to build.

I'd like to hope that we can avoid this kind of problem when the module system is in use by keeping the VM related modules alongside the vm C code; wherever we eventually decide to keep that.

...

make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.

This is very strange - there is no way it should be looking for anything in ../src/src, so clearly there is some wrinkle in the makefile stuff that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!

Like I said, building with a copy of the source ("diff -r oldsrc copiedsrc" verifies that they are the same) doesn't have the same problem. I also manually compared all of the file permissions in the two directories. I have no idea what the difference could possibly be.

Bye, Joshua

tim

On Fri, Dec 28, 2001 at 09:22:31PM +0100, Andreas Raab wrote:

...

...

...

make: *** No rule to make target

`../src/src/Makefile.in', needed by `Makefile'. Stop.

...

This is very strange - there is no way it should be looking

for anything

...

in ../src/src, so clearly there is some wrinkle in the

makefile stuff

...

that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!

Like I said, building with a copy of the source ("diff -r oldsrc copiedsrc" verifies that they are the same) doesn't have the same problem. I also manually compared all of the file permissions in the two directories. I have no idea what the difference could possibly be.

Translating make's error message into a more plain "I am missing the file `../src/src/Makefile.in' and don't know how to create it myself" I would guess that "../src/src/" should probably be "../src/" - so it all looks like a problem with your base directory.

I can see how what I wrote above might be misinterpreted. Here is exactly what I did:

-generate src/ with VMMaker (do chmod a+x, etc.) -tried to build; got error described above

-rm -fr src -generate src with VMMaker (do chmod a+x, etc.) -mv src origsrc -cp -r origsrc src -tried to build; did not get error described above

I verified that the directories src/ and origsrc/ are the same with "diff -r". When I try: -rm -fr src -mv origsrc src -try to build

the error pops up again. Wierd.

Bye, Joshua

Cheers,

• Andreas

On Fri, Dec 28, 2001 at 11:12:59PM +0100, Andreas Raab wrote:

Josh,

...

I can see how what I wrote above might be misinterpreted. Here is exactly what I did:

-generate src/ with VMMaker (do chmod a+x, etc.) -tried to build; got error described above

-rm -fr src -generate src with VMMaker (do chmod a+x, etc.) -mv src origsrc -cp -r origsrc src -tried to build; did not get error described above

I verified that the directories src/ and origsrc/ are the same with "diff -r". When I try: -rm -fr src -mv origsrc src -try to build

the error pops up again. Wierd.

Not weird at all. First of all, does "../src/src/Makefile.in" exist? I bet it doesn't.

Lucky guess. Oh wait, that's what the error message told us ;-)

If not, then there's a simple way to get the error through using cp:

• cp -r origsrc src
• 'touch' the make file causing the problem like in: find . -name Makefile -exec touch {};
• try to build

I bet it's the modification stamp of some Makefile wrt to some other file that (by chance) gets a different stamp with cp (mv is moving files and keeping the dates but cp is creating new ones and thus modifying the date).

Hmm. That make some sense. I still insist that it's weird, tho'; I've never seen a Makefile created by configure that re-invokes configure. Since Makefile is generated, it may be an interaction between timestamps of some other files. I tried touching a few, but was unable to replicate the behavior. Then boredom set in, and I quit.

(NB: If I'm not totally wrong here, why would it be a misinterpretation to point out that Make is just complaining about a non-existing file?! ;-)

I thought that I didn't make it clear that I was doing the exact same thing with two copies of the same source tree; the reason I though that was your hypothesis that "something was wrong with my base directory".

Thanks for the help, Joshua

Cheers,

• Andreas

On Friday 28 December 2001 18:45, Tim Rowledge wrote:

Joshua 'Schwa' Gargus wrote:

...

There is no obvious way to hack around this, since there don't appear to be definitions for these functions anywhere in the source tree. On the off-chance that the source exists in some plugin, I generated the source for all of the plugins; still no luck. Is this a problem with my linux config? I Googled 'signed64BitValueOf' to no avail, which leads me to believe that my Squeak is missing something. Could it be that I have to file in some of John M's recent VM changesets?

Yup, you need the largefiles changes that define the 64bit routines and would fix the off_t error for you. I forgot to call out that particular problem, sorry!

I'd like to hope that we can avoid this kind of problem when the module system is in use by keeping the VM related modules alongside the vm C code; wherever we eventually decide to keep that.

...

make: *** No rule to make target `../src/src/Makefile.in', needed by `Makefile'. Stop.

This is very strange - there is no way it should be looking for anything in ../src/src, so clearly there is some wrinkle in the makefile stuff that can go a little daft. Please, _somebody_ out there is surely knowledgable about this stuff; please help clean it up!

IIRC, the Makefile will run autoconf depending on the timestamps of the various files and autoconf will then screw up the Makefile. Using touch(1) on configure to update the timestamp will hopefully fix it.

Fixing the autoconf stuff would be better but I've no idea how to do that.