December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Programmatic creation of classes Re: [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by StÃ©phane Ducasse

if you compileSilently instead of compile the changes are not logged and this improves the time. Stef On Dec 27, 2011, at 6:15 PM, Guillermo Polito wrote: > DBXMagritteClassBuilderVisitor>>buildAccessorForAttribute: attribute inClass: aClass > could you give me a pointer to read up on what the curly-brace-numbers are? > > The curly braces in the string are just for string formatting, the second one is a dynamic array: > > 'hello {1}! How's your {2}?' format: { 'Ben' 'metaprogramming' }. > > What that method does is creating the accessors, ending up in a final string like this for the mutator: > > 'someAccessor: aParam > instVar := aParam' > > > btw, Can you advise how is the compiling activated? If you had about 800 classes that need to be created, would temporarily turning off the compile assist the program execution time significantly? > > I cannot give a good answer here. Maybe someone has better knowledge on the compiler and it's settings. Maybe creating a giant script with all the class creations is faster than 800 scripts. Or Maybe not significantly :P. Maybe disabling the UI notification enhances it a little bit. > > I've never worried about it a lot :P. > > Cheers, > Guille

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Eliot Miranda

and is there a /lib32/tls? (I hope not). Does anyone have a linux system with either of the following? /lib32/tls /lib64/tls TIA Eliot On Tue, Dec 27, 2011 at 1:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Phillipe, > > On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <kustos(a)gmx.net>wrote: > >> On 27.12.2011 19:18, Eliot Miranda wrote: >> >>> Hi Phillipe, >>> >>> what does ldd answer for the squeak vm? >>> >> >> $ldd coglinux/lib/squeak/4.0-2515/**squeak >> linux-gate.so.1 => (0xffffe000) >> libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) >> libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) >> libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) >> libm.so.6 => /lib32/libm.so.6 (0xf7687000) >> libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) >> libc.so.6 => /lib32/libc.so.6 (0xf750c000) >> /lib/ld-linux.so.2 (0xf76fe000) >> >> It's a 64bit system with 32bit compatibility libraries (only for cog, >> everything else is 64bit). >> > > Ah, ok. Makes sense. So I expect the relevant code needs to read > > # On some old linuxes there is a /lib/tls thread-local-storage version of > the C > # library which the VM may use and if so should take precedence over /lib > libc. > case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in > /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; > /lib/libc*) SVMLLP="/lib:/usr/lib";; > /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; > *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; > exit 1 > esac > > Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of > /usr/lib? > > > >> Cheers >> Philippe >> >> >> > > > -- > best, > Eliot > > -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Eliot Miranda

Hi Phillipe, On Tue, Dec 27, 2011 at 1:33 PM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 27.12.2011 19:18, Eliot Miranda wrote: > >> Hi Phillipe, >> >> what does ldd answer for the squeak vm? >> > > $ldd coglinux/lib/squeak/4.0-2515/**squeak > linux-gate.so.1 => (0xffffe000) > libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) > libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) > libm.so.6 => /lib32/libm.so.6 (0xf7687000) > libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) > libc.so.6 => /lib32/libc.so.6 (0xf750c000) > /lib/ld-linux.so.2 (0xf76fe000) > > It's a 64bit system with 32bit compatibility libraries (only for cog, > everything else is 64bit). > Ah, ok. Makes sense. So I expect the relevant code needs to read # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; /lib32/libc*) SVMLLP="/lib32:/usr/lib32";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac Can you confirm that there is a /usr/lib32 for the 32-bit equivalent of /usr/lib? > Cheers > Philippe > > > -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Philippe Marschall

On 27.12.2011 19:18, Eliot Miranda wrote: > Hi Phillipe, > > what does ldd answer for the squeak vm? $ldd coglinux/lib/squeak/4.0-2515/squeak linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib32/libutil.so.1 (0xf76cb000) libdl.so.2 => /lib32/libdl.so.2 (0xf76c7000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ad000) libm.so.6 => /lib32/libm.so.6 (0xf7687000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf766f000) libc.so.6 => /lib32/libc.so.6 (0xf750c000) /lib/ld-linux.so.2 (0xf76fe000) It's a 64bit system with 32bit compatibility libraries (only for cog, everything else is 64bit). Cheers Philippe

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Andres Valloud

I don't know how to parse "weak set nilling is totally unrelated to finalization", maybe we're talking about different things when we use the term "finalization", I don't know. On 12/27/11 10:59 , Schwab,Wilhelm K wrote: > Is it unrelated by chance/evolution or because that is the correct thing to do? Dolphin does not scope finalization, and the purity of the design is tangible. As I have said, Dolphin began with structured exceptions, hindsight regarding multi-processing, and finalization all in clear view, and these features work together as a result. > > Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage and some associated rough spots. > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves(a)elte.hu] > Sent: Tuesday, December 27, 2011 9:33 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Destiny of changed:/update: > > (quote fixed by hand) > > On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote: > >> I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. >> It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). >> What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)? > > Weak collections are used outside of the scope of finalization, otherwise > most of them wouldn't exist. For example Symbols are stored in WeakSets, so when > a symbol is not used anymore, itcan be garbage collected. And this is > _totally_ unrelated to finalization. > > > Levente > > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves(a)elte.hu] > Sent: Monday, December 26, 2011 9:06 PM > To: Pharo-project(a)lists.gforge.inria.fr; andres.valloud(a)gmail.com > Subject: Re: [Pharo-project] Destiny of changed:/update: > > On Mon, 26 Dec 2011, Andres Valloud wrote: > >> That's not how ephemerons work, and they also get finalized. Both of you may >> be right... > > Well, yes, with ephemerons you can implement a finalization mechanism > which is triggered when the object is _about to be_ garbage collected > (note that the finalize() method in java is similar). But it doesn't mean > that finalization has anything to do with weak collections or that weak > collections should be thread safe, which is what Bill wrote. > > > Levente > >> >> On 12/26/11 16:49 , Levente Uzonyi wrote: >>> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >>> >>>> Levente, >>> >>> Not meaning to be confrontational, but finalization does not happen "in" >>> any type of collection. It happens *to* elements that can be held in any >>> type of weak collection. As a result, they should all be thread safe and >>> self-repairing. >>> >>> >>> I guess you're wrong. A weak collection is a collection which doesn't hold >>> strong references to its elements, so they can be garbage collected when >>> there are no other strong references to them. >>> Finalization is a service which triggers an action when an object is >>> garbage collected. >>> Some finalization techniques require the use of weak collections, but >>> otherwise weak collections are independent of finalization. >>> >>> >>> Levente >>> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi >>> [leves(a)elte.hu] >>> Sent: Monday, December 26, 2011 3:10 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Destiny of changed:/update: >>> >>> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >>> >>>> Stef, >>> >>> I completely agree that events/announcements are cleaner and easier to >>> understand than changed/update. I don't really care whether or not the >>> latter is removed, because I never (directly) use it. Others might prefer >>> to have it retained?? >>> >>> I'm not supposed to say where<g>, but I have seen events, weak collections >>> and finalization done *really* well. In fairness, my working image is old >>> and I need to take another stab at building a recent image, but when I last >>> reviewed them, Pharo's weak collections were lacking features. They have >>> to be thread safe, and they need to clear nil entries left behind by >>> finalization (which is why they must be thread safe). The better we get >>> with events (#on:send:to and friends), the more the current weak >>> collections will appear to be lacking. >>> >>> >>> Finalization only happens in WeakRegistries and those are thread safe. The >>> other weak collections are not subject to finalization, therefore they >>> don't have to be thread safe, that's why they aren't. >>> >>> >>> Levente >>> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >>> [stephane.ducasse(a)inria.fr] >>> Sent: Monday, December 26, 2011 10:56 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Destiny of changed:/update: >>> >>> using on:send: instead of changed/ is a nice way to reduce extra updates. >>> In Cuis juan kept only one mechanism and I like that. >>> >>> In VisualWorks you have to use on:send:to: this way you can select with >>> facet is refreshed. >>> So I would like to deprecated changed. >>> >>> Stef >>> >>>> Will changed:/update: disappear and be totally replaced by Announcements? >>>> >>>> I ask because I'm using ListModel and noticed that it sends a generic >>>> "self >>>> changed: #selectionIndex". I built a GUI that had two of them, and >>>> couldn't >>>> differentiate between the updates, so I was going to enhance it a little. >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> >>>> . >>> >> >> > >> > > . >

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Schwab,Wilhelm K

Eliot, I apologize if this is retreaded ground. I am still using an older, hacked, vm for most of my work. The hacks provided diagnostic information in two ares: (1) can't load an external library? Then it helps to see the full path that was used; at least once, it ended up having an extra slash appended somewhere; various other times, I had not registered something correctly, and the mistake was obvious as soon as I saw what the vm was ultimately trying to load; (2) Can't open a serial port? Then it helps to see how the vm mapped it too. I wish I remembered more of the details on this type of problem. At least some of the trouble I have had is due to the realities of newer hardware forcing me to use USB to serial converters, which I find to be unreliable. I am still sorting through the combination of Linux and some excellent hardware that I have used for years. The short version is that when a library can't load or a port can't open, etc., and the vm did some translation of a name to a number (or vice versa), or manipulated a string, it would be nice to have syslog()/OutputDebugString() output to show what the vm tried to do. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, December 27, 2011 1:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting. Hi Phillipe, what does ldd answer for the squeak vm? The script is trying to work out what default LD_LIBRARY_PATH to supply. The choice is between /lib/tls:/lib:/usr/lib/tls:/usr/lib and /lib:/usr/lib. Older linuxes had two versions of the pthreads library, an experimental one (now the default) using thread-local storage (hence tls) and an older one, I think using the stack pointer to identify the current thread. The script uses ldd to find out what the VM is linked against. Here's the code: # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac On Tue, Dec 27, 2011 at 9:51 AM, Philippe Marschall <kustos(a)gmx.net<mailto:kustos@gmx.net>> wrote: Hi With the latest cog VMs I get: can't infer base LD_LIBRARY_PATH. Aborting. Gentoo 64bit, Linux 3.1 LD_LIBRARY_PATH is not set but libtool is present. Cheers Philippe -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Schwab,Wilhelm K

Is it unrelated by chance/evolution or because that is the correct thing to do? Dolphin does not scope finalization, and the purity of the design is tangible. As I have said, Dolphin began with structured exceptions, hindsight regarding multi-processing, and finalization all in clear view, and these features work together as a result. Squeak (and hence Pharo), by its roots in Smalltalk-80 has a bit more baggage and some associated rough spots. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves(a)elte.hu] Sent: Tuesday, December 27, 2011 9:33 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: (quote fixed by hand) On Tue, 27 Dec 2011, Schwab,Wilhelm K wrote: > I did indeed write that weak collections must be thread safe and self-repairing, which is quite correct. > It has everything to do with finalization, which can be applied to any object (e.g. the handle body pattern). > What good are weak collections if they either prevent garbage collection of their elements (are hence not weak) or can't cope with the finalization of objects that are removed by the garbage collection that they (correctly) did not prevent (incomplete implementation)? Weak collections are used outside of the scope of finalization, otherwise most of them wouldn't exist. For example Symbols are stored in WeakSets, so when a symbol is not used anymore, itcan be garbage collected. And this is _totally_ unrelated to finalization. Levente Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, December 26, 2011 9:06 PM To: Pharo-project(a)lists.gforge.inria.fr; andres.valloud(a)gmail.com Subject: Re: [Pharo-project] Destiny of changed:/update: On Mon, 26 Dec 2011, Andres Valloud wrote: > That's not how ephemerons work, and they also get finalized. Both of you may > be right... Well, yes, with ephemerons you can implement a finalization mechanism which is triggered when the object is _about to be_ garbage collected (note that the finalize() method in java is similar). But it doesn't mean that finalization has anything to do with weak collections or that weak collections should be thread safe, which is what Bill wrote. Levente > > On 12/26/11 16:49 , Levente Uzonyi wrote: >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Levente, >> >> Not meaning to be confrontational, but finalization does not happen "in" >> any type of collection. It happens *to* elements that can be held in any >> type of weak collection. As a result, they should all be thread safe and >> self-repairing. >> >> >> I guess you're wrong. A weak collection is a collection which doesn't hold >> strong references to its elements, so they can be garbage collected when >> there are no other strong references to them. >> Finalization is a service which triggers an action when an object is >> garbage collected. >> Some finalization techniques require the use of weak collections, but >> otherwise weak collections are independent of finalization. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Levente Uzonyi >> [leves(a)elte.hu] >> Sent: Monday, December 26, 2011 3:10 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> On Mon, 26 Dec 2011, Schwab,Wilhelm K wrote: >> >>> Stef, >> >> I completely agree that events/announcements are cleaner and easier to >> understand than changed/update. I don't really care whether or not the >> latter is removed, because I never (directly) use it. Others might prefer >> to have it retained?? >> >> I'm not supposed to say where<g>, but I have seen events, weak collections >> and finalization done *really* well. In fairness, my working image is old >> and I need to take another stab at building a recent image, but when I last >> reviewed them, Pharo's weak collections were lacking features. They have >> to be thread safe, and they need to clear nil entries left behind by >> finalization (which is why they must be thread safe). The better we get >> with events (#on:send:to and friends), the more the current weak >> collections will appear to be lacking. >> >> >> Finalization only happens in WeakRegistries and those are thread safe. The >> other weak collections are not subject to finalization, therefore they >> don't have to be thread safe, that's why they aren't. >> >> >> Levente >> >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >> [stephane.ducasse(a)inria.fr] >> Sent: Monday, December 26, 2011 10:56 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Destiny of changed:/update: >> >> using on:send: instead of changed/ is a nice way to reduce extra updates. >> In Cuis juan kept only one mechanism and I like that. >> >> In VisualWorks you have to use on:send:to: this way you can select with >> facet is refreshed. >> So I would like to deprecated changed. >> >> Stef >> >>> Will changed:/update: disappear and be totally replaced by Announcements? >>> >>> I ask because I'm using ListModel and noticed that it sends a generic >>> "self >>> changed: #selectionIndex". I built a GUI that had two of them, and >>> couldn't >>> differentiate between the updates, so I was going to enhance it a little. >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Destiny-of-changed-update-tp4234693p4234693.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> >>> . >> > > >

Dec. 27, 2011

Re: [Pharo-project] Destiny of changed:/update:

by Schwab,Wilhelm K

The short answer is "look at other dialects." Pharo's weak collections replace objects with nil. Dolphin's completely "forget" the object. It also does a robust job of handling the trickier side of finalization, such as the fact that an object is allowed to rescue itself at the last minute. All of this put together is what I mean by "thread safe and self-repairing." See it done well, and Pharo looks bad by comparison. I have put wrappers around the weak collections. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Tuesday, December 27, 2011 5:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Destiny of changed:/update: i cannot get it, how weak type containers are related to thread safety? A garbage collection happens instantly for language side , so there is no way how a weak collection can be in inconsistent state when it is not known yet, if object is dead or alive. By accessing an object in weak container, you put it's reference on stack, which means that if GC will happen at that stage, a corresponding object will not be collected until at least next GC phase. Now what is "thread-safe weak collections" and what they should serve for? WeakIdentityKeyDictionary? It is not thread-safe. And why it should, when you can easily make it thread-safe by wrapping it with appropriate container object. What else? WeakArray? it is already thread safe: reads and writes are primitives and size is immutable. What else? weak set? again, put a wrapper around it and you got thread-safety. And what is 'self-repairing'? Can you explain what is it? -- Best regards, Igor Stasenko.

Dec. 27, 2011

Re: [Pharo-project] Programmatic creation of classes Re: [ANN][Beta Release] DBXTools - Magritte Scaffolding - Phoseydon

by Eliot Miranda

On Tue, Dec 27, 2011 at 7:53 AM, Ben Coman <btc(a)openinworld.com> wrote: > Guillermo Polito wrote: > >> *What does Phoseydon beta includes?* >> By now, it reads a database schema, builds a model description from it and >> then allows us to: >> - write classes from that description. >> >> > I am very interested in the programmatic creation of classes. Although my > application is not quite related to database schema. Instead I have a UML > model stored in a database basically defined by two tables t_objects and > t_connector from which I need to create Smalltalk classes, instance > variables, and association & aggregate relationships. I tracked down a lot > of what I want to the methods... > > DBXMagritteClassBuilderVisitor**>>visitDBXEntity: aDBXEntity > for which the answer was obvious in hindsight - just replicating the call > to Object>>subclass::: > > DBXMagritteClassBuilderVisitor**>>buildAccessorForAttribute: attribute > inClass: aClass > could you give me a pointer to read up on what the curly-brace-numbers are? > > btw, Can you advise how is the compiling activated? If you had about 800 > classes that need to be created, would temporarily turning off the compile > assist the program execution time significantly? > regards, Ben > profile it using spyOn: to see where the time goes, and then you'll know. -- best, Eliot

Dec. 27, 2011

Re: [Pharo-project] can't infer base LD_LIBRARY_PATH. Aborting.

by Eliot Miranda

Hi Phillipe, what does ldd answer for the squeak vm? The script is trying to work out what default LD_LIBRARY_PATH to supply. The choice is between /lib/tls:/lib:/usr/lib/tls:/usr/lib and /lib:/usr/lib. Older linuxes had two versions of the pthreads library, an experimental one (now the default) using thread-local storage (hence tls) and an older one, I think using the stack pointer to identify the current thread. The script uses ldd to find out what the VM is linked against. Here's the code: # On some old linuxes there is a /lib/tls thread-local-storage version of the C # library which the VM may use and if so should take precedence over /lib libc. case `/usr/bin/ldd "$BIN/squeak" | /bin/fgrep /libc. | sed 's/^.*=> //'` in /lib/tls/libc*) SVMLLP="/lib/tls:/lib:/usr/lib/tls:/usr/lib";; /lib/libc*) SVMLLP="/lib:/usr/lib";; *) echo "can't infer base LD_LIBRARY_PATH. Aborting." 1>&2; exit 1 esac On Tue, Dec 27, 2011 at 9:51 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > Hi > > With the latest cog VMs I get: > > can't infer base LD_LIBRARY_PATH. Aborting. > > Gentoo 64bit, Linux 3.1 > > LD_LIBRARY_PATH is not set but libtool is present. > > Cheers > Philippe > > > -- best, Eliot

Dec. 27, 2011