quote:

---

>
> Fred Ma <fma@doe.carleton.ca> writes in comp.unix.solaris:
> |I first have to find out if gcc
> |on solaris is even using either one of newlib
> |or glibc.
>
> Unless you specifically compiled and installed one of those, it will
> normally use the libc built into Solaris. (For a long time GNU libc
> wouldn't build on Solaris at all - I don't know if they ever fixed
> that.)
> ________________________________________
________________________________
> Alan Coopersmith alanc@alum.calberkeley.org
> http://www.CSUA.Berkeley.EDU/~alanc/ aka: Alan.Coopersmith@Sun.COM
> Working for, but definitely not speaking for, Sun Microsystems, Inc.

---

quote:

---

> Alan Coopersmith wrote:
>
>
>
> Thank goodness the sun libc uses long_int for time_t,
> same as newlib. Is there a way to make sure, though,
> for any unix-based gcc? I'm hoping there is a sure-
> fire way to issue a command to find out what libc
> program will use (not necessarily for this case).
> tried the -v option with gcc, but not sure what detail
> in the output is the decisive information (attached
> below).
>
> At the risk of sounding like I'm edging in a new topic,
> I'd like to mention a very much related question. I am
> actually calling my C++ code from a mathematical
> computation environment called Matlab. It provides a
> command line (and GUI) for the user to perform a series
> of (potentially very complex) calculations, possibly by
> invoking command scripts. Do I have to worry about
> what libc is used by matlab? It provides some means of
> passing data back and forth, and my program can call
> some dynamic library routines to execute commands back
> in the matlab workspace (a separate space from the one
> in which my code runs).
>
> I guess the generalization of the above question is, if
> some package calls one's own c++ code, does the
> programmer have to watch out for problems that can
> arise from not using the same libc as the package.
> Pretty open-ended, I admit. But thanks if anyone can
> provide their own thoughts on that, anecdotal or
> otherwise. If the answer is that pitfalls can arise,
> then I wonder if a matlab gurue can say what libc is
> used by their package (solaris 8 in this case, release
> 13), and what are the most common pitfalls when using
> different libc's.
>
> Fred
>

---

quote:

---

> Alan Coopersmith wrote:
>
>
>
> Thank goodness the sun libc uses long_int for time_t,
> same as newlib. Is there a way to make sure, though,
> for any unix-based gcc? I'm hoping there is a sure-
> fire way to issue a command to find out what libc
> program will use (not necessarily for this case).
> tried the -v option with gcc, but not sure what detail
> in the output is the decisive information (attached
> below).
>
> At the risk of sounding like I'm edging in a new topic,
> I'd like to mention a very much related question. I am
> actually calling my C++ code from a mathematical
> computation environment called Matlab. It provides a
> command line (and GUI) for the user to perform a series
> of (potentially very complex) calculations, possibly by
> invoking command scripts. Do I have to worry about
> what libc is used by matlab? It provides some means of
> passing data back and forth, and my program can call
> some dynamic library routines to execute commands back
> in the matlab workspace (a separate space from the one
> in which my code runs).
>
> I guess the generalization of the above question is, if
> some package calls one's own c++ code, does the
> programmer have to watch out for problems that can
> arise from not using the same libc as the package.
> Pretty open-ended, I admit. But thanks if anyone can
> provide their own thoughts on that, anecdotal or
> otherwise. If the answer is that pitfalls can arise,
> then I wonder if a matlab gurue can say what libc is
> used by their package (solaris 8 in this case, release
> 13), and what are the most common pitfalls when using
> different libc's.
>
> Fred
>

---

quote:

---

>
> If you type:
>
> ldd matlab
>
> at the UNIX prompt in the <matlabroot>/bin/sol2 directory, it will tell
> you which libc matlab is using.

---

quote:

---

>
> If you type:
>
> ldd matlab
>
> at the UNIX prompt in the <matlabroot>/bin/sol2 directory, it will tell
> you which libc matlab is using.

---

quote:

---

> libc.so.1 => /usr/lib/libc.so.1

---

quote:

---

> libc.so.1 => /usr/lib/libc.so.1

---

quote:

---

> Fred Ma <fma@doe.carleton.ca> writes:
>
>
> I bet on that one :-)

---

quote:

---

> Fred Ma <fma@doe.carleton.ca> writes:
>
>
> I bet on that one :-)

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else?

---

quote:

---

> And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else?

---

quote:

---

> And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message
> news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else? And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,
> and also wishfully hoping to be retrievable.
> As I mentioned, I can probably safely assume
> that it I'm using sun's libc. But what about
> in general?
>
> Fred

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message
> news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else? And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,
> and also wishfully hoping to be retrievable.
> As I mentioned, I can probably safely assume
> that it I'm using sun's libc. But what about
> in general?
>
> Fred

---

quote:

---

> All the suggested commands are very revealing
> (not ar): nm, objdump, strings.
>
> There is probably some documentation somewhere,
> but where to start looking? Any nonsun libc
> will probably have been installed by an adminstrator
> prior the our current one. The current administrator
> is not a software person (or perhaps, he is, but
> very quiet about it). But the above commands make
> it pretty clear that in fact, the libc is suns.

---

quote:

---

> All the suggested commands are very revealing
> (not ar): nm, objdump, strings.
>
> There is probably some documentation somewhere,
> but where to start looking? Any nonsun libc
> will probably have been installed by an adminstrator
> prior the our current one. The current administrator
> is not a software person (or perhaps, he is, but
> very quiet about it). But the above commands make
> it pretty clear that in fact, the libc is suns.

---

quote:

---

>
> libc doesn't have user servicable parts -- there are internal
> machinations between libc, the kernel, the runtime linker, the
> threads library, various other system libraries, etc.

---

quote:

---

> An easy way to tell Sun-supplied objects from (non-malicious)
> others is to use what(1) on them:
>
> % what /lib/libc.so.1
> /usr/lib/libc.so.1:
> SunOS 5.9 Generic 112874-14 Jan 2003
>
> The core SunOS binaries and libraries all have such strings --
> other parts of Solaris vary.

---

quote:

---

>
> libc doesn't have user servicable parts -- there are internal
> machinations between libc, the kernel, the runtime linker, the
> threads library, various other system libraries, etc.

---

quote:

---

> An easy way to tell Sun-supplied objects from (non-malicious)
> others is to use what(1) on them:
>
> % what /lib/libc.so.1
> /usr/lib/libc.so.1:
> SunOS 5.9 Generic 112874-14 Jan 2003
>
> The core SunOS binaries and libraries all have such strings --
> other parts of Solaris vary.

---

quote:

---

> jonathan-ggl@ofb.net (Jonathan Adams) wrote in message news:<99d37172.0311230324.d50627c@posting.google.com>...
>
> No, but it can be very useful to know what library
> is being targetted by C code.

---

quote:

---

>
> This is indeed a very handy command. Ours is
> located at /usr/xpg4/bin/.

---

quote:

---

> jonathan-ggl@ofb.net (Jonathan Adams) wrote in message news:<99d37172.0311230324.d50627c@posting.google.com>...
>
> No, but it can be very useful to know what library
> is being targetted by C code.

---

quote:

---

>
> This is indeed a very handy command. Ours is
> located at /usr/xpg4/bin/.

---

quote:

---

> fma@doe.carleton.ca (fred ma) wrote in message news:<c625d2ec.0311231755.fa72a8@posting.google.com>...
>
> Oh, certainly -- ldd(1) and pldd(1) are the tools to use for this, on
> Solaris. I was just remarking on the 'nonsun libc' comment -- it
> would be pretty difficult to do, and not worth most of the trouble.
> (unless it was just a wrapper over the Sun libc)

---

quote:

---

> fma@doe.carleton.ca (fred ma) wrote in message news:<c625d2ec.0311231755.fa72a8@posting.google.com>...
>
> Oh, certainly -- ldd(1) and pldd(1) are the tools to use for this, on
> Solaris. I was just remarking on the 'nonsun libc' comment -- it
> would be pretty difficult to do, and not worth most of the trouble.
> (unless it was just a wrapper over the Sun libc)

---

quote:

---

>
> Fred Ma <fma@doe.carleton.ca> writes in comp.unix.solaris:
> |I first have to find out if gcc
> |on solaris is even using either one of newlib
> |or glibc.
>
> Unless you specifically compiled and installed one of those, it will
> normally use the libc built into Solaris. (For a long time GNU libc
> wouldn't build on Solaris at all - I don't know if they ever fixed
> that.)
> ________________________________________
________________________________
> Alan Coopersmith alanc@alum.calberkeley.org
> http://www.CSUA.Berkeley.EDU/~alanc/ aka: Alan.Coopersmith@Sun.COM
> Working for, but definitely not speaking for, Sun Microsystems, Inc.

---

quote:

---

> Alan Coopersmith wrote:
>
>
>
> Thank goodness the sun libc uses long_int for time_t,
> same as newlib. Is there a way to make sure, though,
> for any unix-based gcc? I'm hoping there is a sure-
> fire way to issue a command to find out what libc
> program will use (not necessarily for this case).
> tried the -v option with gcc, but not sure what detail
> in the output is the decisive information (attached
> below).
>
> At the risk of sounding like I'm edging in a new topic,
> I'd like to mention a very much related question. I am
> actually calling my C++ code from a mathematical
> computation environment called Matlab. It provides a
> command line (and GUI) for the user to perform a series
> of (potentially very complex) calculations, possibly by
> invoking command scripts. Do I have to worry about
> what libc is used by matlab? It provides some means of
> passing data back and forth, and my program can call
> some dynamic library routines to execute commands back
> in the matlab workspace (a separate space from the one
> in which my code runs).
>
> I guess the generalization of the above question is, if
> some package calls one's own c++ code, does the
> programmer have to watch out for problems that can
> arise from not using the same libc as the package.
> Pretty open-ended, I admit. But thanks if anyone can
> provide their own thoughts on that, anecdotal or
> otherwise. If the answer is that pitfalls can arise,
> then I wonder if a matlab gurue can say what libc is
> used by their package (solaris 8 in this case, release
> 13), and what are the most common pitfalls when using
> different libc's.
>
> Fred
>

---

quote:

---

>
> If you type:
>
> ldd matlab
>
> at the UNIX prompt in the <matlabroot>/bin/sol2 directory, it will tell
> you which libc matlab is using.

---

quote:

---

> libc.so.1 => /usr/lib/libc.so.1

---

quote:

---

> Fred Ma <fma@doe.carleton.ca> writes:
>
>
> I bet on that one :-)

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else?

---

quote:

---

> And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message
> news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else? And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,
> and also wishfully hoping to be retrievable.
> As I mentioned, I can probably safely assume
> that it I'm using sun's libc. But what about
> in general?
>
> Fred

---

quote:

---

> All the suggested commands are very revealing
> (not ar): nm, objdump, strings.
>
> There is probably some documentation somewhere,
> but where to start looking? Any nonsun libc
> will probably have been installed by an adminstrator
> prior the our current one. The current administrator
> is not a software person (or perhaps, he is, but
> very quiet about it). But the above commands make
> it pretty clear that in fact, the libc is suns.

---

quote:

---

>
> libc doesn't have user servicable parts -- there are internal
> machinations between libc, the kernel, the runtime linker, the
> threads library, various other system libraries, etc.

---

quote:

---

> An easy way to tell Sun-supplied objects from (non-malicious)
> others is to use what(1) on them:
>
> % what /lib/libc.so.1
> /usr/lib/libc.so.1:
> SunOS 5.9 Generic 112874-14 Jan 2003
>
> The core SunOS binaries and libraries all have such strings --
> other parts of Solaris vary.

---

quote:

---

> jonathan-ggl@ofb.net (Jonathan Adams) wrote in message news:<99d37172.0311230324.d50627c@posting.google.com>...
>
> No, but it can be very useful to know what library
> is being targetted by C code.

---

quote:

---

>
> This is indeed a very handy command. Ours is
> located at /usr/xpg4/bin/.

---

quote:

---

> fma@doe.carleton.ca (fred ma) wrote in message news:<c625d2ec.0311231755.fa72a8@posting.google.com>...
>
> Oh, certainly -- ldd(1) and pldd(1) are the tools to use for this, on
> Solaris. I was just remarking on the 'nonsun libc' comment -- it
> would be pretty difficult to do, and not worth most of the trouble.
> (unless it was just a wrapper over the Sun libc)

---

quote:

---

>
> Fred Ma <fma@doe.carleton.ca> writes in comp.unix.solaris:
> |I first have to find out if gcc
> |on solaris is even using either one of newlib
> |or glibc.
>
> Unless you specifically compiled and installed one of those, it will
> normally use the libc built into Solaris. (For a long time GNU libc
> wouldn't build on Solaris at all - I don't know if they ever fixed
> that.)
> ________________________________________
________________________________
> Alan Coopersmith alanc@alum.calberkeley.org
> http://www.CSUA.Berkeley.EDU/~alanc/ aka: Alan.Coopersmith@Sun.COM
> Working for, but definitely not speaking for, Sun Microsystems, Inc.

---

quote:

---

> Alan Coopersmith wrote:
>
>
>
> Thank goodness the sun libc uses long_int for time_t,
> same as newlib. Is there a way to make sure, though,
> for any unix-based gcc? I'm hoping there is a sure-
> fire way to issue a command to find out what libc
> program will use (not necessarily for this case).
> tried the -v option with gcc, but not sure what detail
> in the output is the decisive information (attached
> below).
>
> At the risk of sounding like I'm edging in a new topic,
> I'd like to mention a very much related question. I am
> actually calling my C++ code from a mathematical
> computation environment called Matlab. It provides a
> command line (and GUI) for the user to perform a series
> of (potentially very complex) calculations, possibly by
> invoking command scripts. Do I have to worry about
> what libc is used by matlab? It provides some means of
> passing data back and forth, and my program can call
> some dynamic library routines to execute commands back
> in the matlab workspace (a separate space from the one
> in which my code runs).
>
> I guess the generalization of the above question is, if
> some package calls one's own c++ code, does the
> programmer have to watch out for problems that can
> arise from not using the same libc as the package.
> Pretty open-ended, I admit. But thanks if anyone can
> provide their own thoughts on that, anecdotal or
> otherwise. If the answer is that pitfalls can arise,
> then I wonder if a matlab gurue can say what libc is
> used by their package (solaris 8 in this case, release
> 13), and what are the most common pitfalls when using
> different libc's.
>
> Fred
>

---

quote:

---

>
> If you type:
>
> ldd matlab
>
> at the UNIX prompt in the <matlabroot>/bin/sol2 directory, it will tell
> you which libc matlab is using.

---

quote:

---

> libc.so.1 => /usr/lib/libc.so.1

---

quote:

---

> Fred Ma <fma@doe.carleton.ca> writes:
>
>
> I bet on that one :-)

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else?

---

quote:

---

> And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,

---

quote:

---

> Maurizio Loreti <mlo@foobar.it> wrote in message
> news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
>
>
> Maurizio,
>
> I'm sure you're right. But is there a way to
> find out if that libc.so.1 was a newlib, a
> glibc, sun's libc, or something else? And the
> verion as well? That's the information I was
> wishfully hoping to be embedded in the library,
> and also wishfully hoping to be retrievable.
> As I mentioned, I can probably safely assume
> that it I'm using sun's libc. But what about
> in general?
>
> Fred

---

quote:

---

> All the suggested commands are very revealing
> (not ar): nm, objdump, strings.
>
> There is probably some documentation somewhere,
> but where to start looking? Any nonsun libc
> will probably have been installed by an adminstrator
> prior the our current one. The current administrator
> is not a software person (or perhaps, he is, but
> very quiet about it). But the above commands make
> it pretty clear that in fact, the libc is suns.

---

quote:

---

>
> libc doesn't have user servicable parts -- there are internal
> machinations between libc, the kernel, the runtime linker, the
> threads library, various other system libraries, etc.

---

quote:

---

> An easy way to tell Sun-supplied objects from (non-malicious)
> others is to use what(1) on them:
>
> % what /lib/libc.so.1
> /usr/lib/libc.so.1:
> SunOS 5.9 Generic 112874-14 Jan 2003
>
> The core SunOS binaries and libraries all have such strings --
> other parts of Solaris vary.

---

quote:

---

> jonathan-ggl@ofb.net (Jonathan Adams) wrote in message news:<99d37172.0311230324.d50627c@posting.google.com>...
>
> No, but it can be very useful to know what library
> is being targetted by C code.

---

quote:

---

>
> This is indeed a very handy command. Ours is
> located at /usr/xpg4/bin/.

---

quote:

---

> fma@doe.carleton.ca (fred ma) wrote in message news:<c625d2ec.0311231755.fa72a8@posting.google.com>...
>
> Oh, certainly -- ldd(1) and pldd(1) are the tools to use for this, on
> Solaris. I was just remarking on the 'nonsun libc' comment -- it
> would be pretty difficult to do, and not worth most of the trouble.
> (unless it was just a wrapper over the Sun libc)

---