[M3devel] my status on win32

Sun Jan 20 20:12:45 CET 2008

"mapped" is probably a poor choice of words here.  Sorry.
--Randy

>>> Jay <jayk123 at hotmail.com> 1/19/2008 11:27 PM >>>
What does "mapped" mean here?

The way it works, on Modula-3 NT386, and I haven't seen this done quite
this way ever on Win32, not so
systematically/mechanically/automatically, and I don't know how Posixish
systems work here, but the way it works is that for every .dll, CM3
NT386 builds foo.lib and foo.lib.sa.

foo.lib is an "import lib", just containing essentially function names
and a file name.
foo.lib.sa is a regular old static .lib, sa for standalone.

You can also just build a static .lib -- for stuff that is never a
.dll, for stuff that is only used once, but is broken up into multiple
directories.
For example m3quake, m3middle, m3objfile, m3back, etc. They are only
used by cm3 so are just static .libs, just foo.lib, are built.
(If we fix cm3.exe to be copy over itself, and I have some new clever
ideas here, it might be profitable, for "developer productivity", to
turn these into .dlls -- just so I can cd around and rebuild/reship
less.)

When you ask to build a standalone executable, we have a list of .libs,
foo.lib, bar.lib. They are full paths.
For each one, we see if foo.lib.sa exists, and if so, we use that
instead of foo.lib.

It is all rather simple and clever, but at least to me, it was
surprising and new, so I explain it here.
Perhaps Posixish systems work very similarly and this is old hat?
I know cm3 doesn't implement this for Posix, but ar/ld/gcc could be
handling things this way underneath for it.

For example, I know on Mac OS X, if you link to a full path to a file,
that's what you get.
But if you say -Ldirectory -lfoo, ld probes for directory/foo.dylib and
then directory/foo.a.
So modulo the extensions and unknown to me how you build the things in
the first place, same thing.
You have to be sure to use the setting to split lib paths like that,
otherwise you break dynamic linking.

CM3 makes foo.sa.lib with its own mklib. This is also unusual. Normally
one would use lib.exe or link.exe /lib for this,
or ar/ld/gcc/dlltools. But the CM3 folks were obviously, openly en
route to cutting dependencies through
reimplementation.
I had some initial trouble on NT385GNU building static .libs with
ar/ld/gcc/dlltool, so, heck, I just do what NT386 does, and
it seems to be working (modulo that SOMETHING is not working :) ).

I don't want to stop anyone else from debugging this but if nobody else
figures it out I will try.
I can repro it easily, thanks for the good repro Randy! (though I wish
it would crash instead of mis-display :) )

There is no "vendor's equivalent library" here, it is all just Modula-3
foo.lib or foo.lib.sa.
Look at NT386/*.txt, by the .exe.
Build one way.
Rename away NT386.
Build the other way.
Compare the directories.
You will see what I am talking about.

 - Jay

Date: Sat, 19 Jan 2008 21:12:37 -0500
From: rcoleburn at scires.com 
To: hosking at cs.purdue.edu; wagner at elegosoft.com 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] my status on win32

Hi Tony:

Are you suggesting that when the program is built standalone it maps
libraries differently?  I know there is a difference between dynamic vs.
static libraries, but are you suggesting that a different library is
being mapped than the vendor's equivalent of the dynamic library?  How
would I check for this situation?

Your suggestion seems plausible since the source is not recompiled;
instead, the linker is used to change the way the EXE is put together
and that seems to cause the difference in operation as far as pixmaps
are concerned.

Regards,
Randy

>>> Tony Hosking <hosking at cs.purdue.edu> 1/19/2008 6:47 PM >>>
I would perhaps suspect a bad library mapping.

On Jan 19, 2008, at 2:48 PM, Olaf Wagner wrote:

> Quoting Randy Coleburn <rcoleburn at scires.com>:
>> 1.  pixmaps aren't rendered properly on the screen.  They look
really
>> bad.  I recall having this problem a while back with one of the
early
>> 5.x releases, so I guess it was never solved.  I've got some old
test
>> programs I try to dig out and see if I can find out what is going  
>> on.  I
>> seem to recall that building standalone in the past seemed to fix
the
>> problem, so this is a real mystery.
>
> Hi Randy,
>
> I'm afraid I wasn't able to solve it directly some years ago and
> then forgot about it due to more urgent tasks.
>
> I think we should try to narrow down the location of the problem
> (i.e. is it in the runtime, code generation, linker, or windows
> libraries).
>
> As you still have the 4.1 code of the Windows libraries, could you
> first try to build them with the new compiler and see if it makes
> a difference if you link against them?
>
> It may also be worthwhile to compare the commands actually used
> for linking (use -commands). That is, before we turn to the actual
> generated code...
>
> I still haven't got Windows access here, so I can just suggest what
> to do...
>
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 

> 45 86 95
>    http://www.elegosoft.com ( http://www.elegosoft.com/ ) |
Geschäftsführer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>

Helping your favorite cause is as easy as instant messaging. You IM, we
give. Learn more. (
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080120/be5a4c80/attachment-0002.html>