[M3devel] my status on win32

[Jay]

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 | 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.
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/1423376e/attachment-0002.html>