Greetings! Just a recap of the frenzied notes last night -- I've committed code to avoid the problematic functions when linking statically, so ACL2 should work out of the box.
It is quite irritating that libc.a provides functions which open shared libs on invocation (!). We may have solved the problem for now, but what if some future libc version decides to launch libm when calling exp()? Perhaps someone knows of a non-ad-hoc reason why these and only these (password, network) functions must be handled this way. user-homedir-pathname will now default to "~/" if the password file lookup functions cannot be run, which should be OK on linux et.al. at least. Hostname lookups will fail gracefully, ~ expansion in filenames won't happen, and file-author will fail, until we figure out a better way. Suggestions and advice most appreciated. Take care, Robert Boyer <[EMAIL PROTECTED]> writes: > > So Bob, is your definition of user-homedir-pathname a redefinition? > > My definition is a complete crock that should be utterly abandoned when > someone figures out what the right thing to do is. Currently, if you call > the built-in user-homedir-pathname in a 2.7.0 static GCL, it throws away half > (1 GB) of one's possible address space, believe it or not, due to some very > strange Linux/virtual memory crapola. Or causes an error. Just something to > be done right when and if anyone can figure out what that is. It's amazing > that Camm tracked this down as the source of the problem we were having. > > Bob > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
