[M3devel] ROOT

[Jay]

 > why did you introduce a dependency to the new m3core


I had removed link because it wasn't used, and/or didn't introduce it the first builds of e.g. AMD64_LINUX.

 

Link naturally goes in m3core/src/unix.

 

However implementing it locally in cm3 is reasonable.

I should have tried harder on a clean local unshared solution.

Not every .c file needs m3unix.h, though I am comforted by using it, that I have things all setup well and portably.

 

Waitpid changes similar, you'll recall.

 

 - Jay

 


CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Subject: Re: [M3devel] ROOT
Date: Thu, 2 Jul 2009 16:02:56 -0400





Yes, now I remember.  We need to build a new compiler (from the new m3front) in order to compile features (LONGINT) in the new m3core.  This implies the need for compilations upstream of m3core to function with both old and new versions.  So, my question now is why did you introduce a dependency from the new cm3 to the new m3core?  That should probably be avoided.


On 2 Jul 2009, at 15:23, Jay wrote:


>> But why would you compile a new cm3 with an old m3core?
 
That is what the "release" builds do on the Tinderbox.
  If you can fix that, please do. :)
Notice how I broke them the other day?
But not the "last ok" build?

They start with a 5.4 compiler.
 They do NOT build m3core, libm3.
 Not sure about m3cc.
 They start with sysutils, then, in whatever order,
   m3quake, m3middle, m3front, m3back, cm3.
 Then they use that new cm3 to build
   m3cc if not done already 
  (clean)
   m3core, libm3, sysutils, m3front/quake/back/middle, cm3.

At some point, you know, cm3 could not build m3core, when
cm3 didn't know about LONGINT and m3core used it.
I don't know if 5.4 is such a version.
 
 
 > I thought the use of -rpath overcomes the need for LD_LIBRARY_PATH?
 
That's not the entire story.
If you use -rpath and point to /usr/local/cm3/pkg/foo/linux, then
  - you end up with a huge presumably inefficient runpath
   This can be addressed by using /usr/local/cm3/lib instead.
 
  - you end up with insecure /tmp for distribution builds
  This can be addressed by using $origin or changing how distribution builds are done.
 
 - You can't "easily" move the install. Though there are utilities in various OSes to edit the paths later, or you can relink upon install. I didn't make that strategy up.

  > Is LD_LIBRARY_PATH so bad if you insist on moving the libraries someplace other than the rpath used in their linkage?

 
I don't understand. Right, if you want to move stuff around, LD_LIBRARY_PATH is one solution. $origin is another. They aren't equivalent and they have various pluses/minus. Searching the web definitely leads me to favor $origin.
"The Sun linker developer say so." Plus, LD_LIBRARY_PATH is not scoped to a particular executable, unless you use wrapper scripts. /etc/ld.so.conf or such on birch including /usr/local/cm3/lib broke my own use of my $HOME/cm3/bin, because those binaries are supposed to use $HOME/cm3/lib, but there is (often) just one LD_LIBRARY_PATH, again, unless you write wrapper scripts.
 

If we force everyone to install to /usr/local/cm3 or /opt/cm3, the issue is reduced, granted





- Jay







________________________________


CC: m3devel at elegosoft.com


From: hosking at cs.purdue.edu


To: jay.krell at cornell.edu


Subject: Re: [M3devel] ROOT


Date: Thu, 2 Jul 2009 12:40:18 -0400





I'm not talking about m3overrides. That is a arguably a special-purpose hack. We shouldn't layer a hack into the *normal* build process.








Antony Hosking | Associate Professor | Computer Science | Purdue University


305 N. University Street | West Lafayette | IN 47907 | USA


Office +1 765 494 6001 | Mobile +1 765 427 5484














On 2 Jul 2009, at 12:19, Jay wrote:








Seems broken to me to depend on


the source directory structure





Like m3overrides? But yes, I agree.


m3overrides seems broken too.





- Jay


























----------------------------------------


From: hosking at cs.purdue.edu


To: m3devel at elegosoft.com


Date: Thu, 2 Jul 2009 11:49:34 -0400


Subject: [M3devel] ROOT





Where did variable ROOT come from? Do I really need to define it?


Seems broken to me to depend on the source directory structure as it


sets that structure in stone.













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090702/324a37ce/attachment-0002.html>