[M3devel] ROOT

[Jay]

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