Re: [osol-discuss] Compiler mailing list?
I work in the Sun Studio group. The tools-discuss alias has a fair amount of non-compiler traffic. I'm subscribed, but I don't get a chance to go through the email every day. If there was a tools-compilers (for Sun Studio and gcc) or something similar, I think I'd be able to respond to it more quickly. And I might be able to get some other Sun engineers in my area to sign up. I also subscribe to all the horrible "forum updated" emails, but I plow through those even less frequently than I check the tools-discuss alias emails. There is some new management interest being revived for adding proper email support to the SDN forums, but you never know if that will fly, or how long it will take. It doesn't seem like it should be that much trouble to create a new alias for "OpenSolaris-related compiler questions". It would undoubtedly also collect questions about compiler-bundled tools (like dbx), and compiler questions that are not related directly to OpenSolaris. But I think that seems okay. If it eventually gets replaced by another alias, when we get proper gateways in Sun Studio forums, that should be okay too. Just my .02 --chris This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [tools-linking] ld.so refuses to properly handle paths with colon
My initial thoughts are:
1. add an escape character of some kind to insert a literal ':'
2. please make all pathnames use a consistent syntax
3. don't implement any special work arounds unless you know there are
users of the feature
4. dlopen("foo:bar", RTLD_LAZY | RTLD_FULLPATH)
This is really gross! I always thought I was just passing
a library, not a list! Is this true for all rtld
functions that take a library name?
So I see two different kinds of strings we are dealing with:
1. a colon-separated list of directories (can be a list of one)
2. a colon-separated list of libraries (can be a list of one)
Is that true?
$ISALIST could be implemented by using direct iteration right?
It doesn't actually have to expand to a colon-separated
list of libraries, does it? Does anyone use that feature otherwise?
Can we pretend it was a bug, and remove that feature? ;-)
--chris
Rod Evans wrote:
Presently, no. But it seems like a mechanism to allow ':' within
a path is now desirable.
I've a couple of thoughts. First, if you wish to allow ':' within
a dlopen() path, would you also want to allow this character in
a RUNPATH, LD_LIBRARY_PATH, or some other ld.so.1 processed path?
We could invent an escape character that can be embedded in a path.
This provides generic flexibility, but in the case of dlopen()
might require the user to translate a string (read from some config
file?) to include the escape character.
Or, we could allow dlopen() path processing to differ/be-more-flexible
than other path processing. We could force a dlopen() string to be
used as-is. This changes todays behavior, and would break the example
I had cited below. But, would anyone care? Or we could be explicit
in regards our new requirement:
dlopen("foo:bar", RTLD_LAZY | RTLD_FULLPATH)
and use a new token to define a path should be used as is.
Thoughts?
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] cc MIA?
The /usr/bin/cc link is now owned by the new "sunstudio12u1" package which is the latest FCS release of Sun Studio. You probably should just install "sunstudio12u1". Many managers were involved in the decision about what should and should not be on your default search path when you had certain packages installed. ;-) It's not clear to me we got the best outcome. In the long run, I think /usr/bin/cc will always point to the latest FCS/stable version of cc. I hope we won't have to cause any surprises like this in the future. --chris -- This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
