Alan Coopersmith wrote:
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.



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
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

P.S.  Sorry for the repost, but I forgot to attach
the following.  Hopefully, my request to cancel
the post without this attachment was made promptly
enough.
 ========================================
====================

Attached output from "gcc -v"

Note: "gfilt" is the script that calls gcc and
additionally pretties up the messages related to
the C++ Standard Template Library ("STL Message
Decryptor")

Comments relating to compilation date and hostname
are printed by my make file.

------------------------------------------------------------
make -f Makefile.mine
make[1]: Entering directory `/home/fma/Applications/Cmln/FFT/PandR/STL'
malawi Wed Nov 19 16:25:53 EST 2003
Compiling with Matlab....
gfilt -DHOST=malawi -W -Wall -fmessage-length=0 -Wno-deprecated -Wno-unused-
variable -pedantic -Wno-sign-compare  -v    \
-DMATLAB_MEX_FILE \
-o client.mexsol \
client.cpp Routines.cpp mexversion.c \
-fPIC \
-shared \
-Wl,-M,/opt/matlab13/extern/lib/sol2/mexFunction.map \
-L /opt/matlab13/bin/sol2 -lmx -lmex -lmat -lm
BD Software STL Message Decryptor v2.32 for gcc (03/22/2003)
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/specs
Configured with: ../configure --disable-nls --with-as=/usr/ccs/bin/as --with
-
ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 3.2.1
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/cc1plus -v -iprefix /CMC/
tools/synopsys/sim/sparcOS5/gcc/gcc-2.6.3/lib/gcc-lib/sparc-sun-solaris2.8/
3.2.1/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -
D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -
D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -
D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix
-Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500 -
D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D__EXTENSIONS__ -
D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int
-D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -
DHOST=malawi -DMATLAB_MEX_FILE client.cpp -D__GNUG__=3 -D__EXCEPTIONS -quiet
-dumpbase client.cpp -W -Wall -Wno-deprecated -Wno-unused-variable -Wno-
sign-compare -pedantic -version -fmessage-length=0 -fmessage-length=0 -fPIC
-o /var/tmp//cc3TMsh8.s
GNU CPP version 3.2.1 (cpplib) (sparc ELF)
GNU C++ version 3.2.1 (sparc-sun-solaris2.8)
compiled by GNU C version 3.2.1.
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1/sparc-
sun-solaris2.8"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1/
backward"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/include"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../sparc-sun-solaris2.8/
include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/lib/gcc-lib/../../sparc-sun-solar
is2.
8/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc-lib/../../include/c++/3.2.1
/usr/local/lib/gcc-lib/../../include/c++/3.2.1/sparc-sun-solaris2.8
/usr/local/lib/gcc-lib/../../include/c++/3.2.1/backward
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/include
/usr/include
End of search list.
/usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccVGSfa9.o /var/tmp//cc3TMsh8.
s
/usr/ccs/bin/as: Sun WorkShop 6 99/08/18
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/cc1plus -v -iprefix /CMC/
tools/synopsys/sim/sparcOS5/gcc/gcc-2.6.3/lib/gcc-lib/sparc-sun-solaris2.8/
3.2.1/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -
D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -
D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -
D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix
-Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500 -
D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D__EXTENSIONS__ -
D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int
-D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -
DHOST=malawi -DMATLAB_MEX_FILE Routines.cpp -D__GNUG__=3 -D__EXCEPTIONS -
quiet -dumpbase Routines.cpp -W -Wall -Wno-deprecated -Wno-unused-variable -
Wno-sign-compare -pedantic -version -fmessage-length=0 -fmessage-length=0 -
fPIC -o /var/tmp//cc3TMsh8.s
GNU CPP version 3.2.1 (cpplib) (sparc ELF)
GNU C++ version 3.2.1 (sparc-sun-solaris2.8)
compiled by GNU C version 3.2.1.
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1/sparc-
sun-solaris2.8"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1/
backward"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/include"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../sparc-sun-solaris2.8/
include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/lib/gcc-lib/../../sparc-sun-solar
is2.
8/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc-lib/../../include/c++/3.2.1
/usr/local/lib/gcc-lib/../../include/c++/3.2.1/sparc-sun-solaris2.8
/usr/local/lib/gcc-lib/../../include/c++/3.2.1/backward
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/include
/usr/include
End of search list.
/usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccN1AbMQ.o /var/tmp//cc3TMsh8.
s
/usr/ccs/bin/as: Sun WorkShop 6 99/08/18
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/cc1plus -v -iprefix /CMC/
tools/synopsys/sim/sparcOS5/gcc/gcc-2.6.3/lib/gcc-lib/sparc-sun-solaris2.8/
3.2.1/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -
D__GXX_ABI_VERSION=102 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -
D__PRAGMA_REDEFINE_EXTNAME -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -
D__SVR4 -D__PRAGMA_REDEFINE_EXTNAME -D__sparc -D__sun -D__unix -Asystem=unix
-Asystem=svr4 -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_XOPEN_SOURCE=500 -
D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -D__EXTENSIONS__ -
D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__WCHAR_TYPE__=long int
-D__WINT_TYPE__=long int -D__GCC_NEW_VARARGS__ -Acpu=sparc -Amachine=sparc -
DHOST=malawi -DMATLAB_MEX_FILE mexversion.c -D__GNUG__=3 -D__EXCEPTIONS -
quiet -dumpbase mexversion.c -W -Wall -Wno-deprecated -Wno-unused-variable -
Wno-sign-compare -pedantic -version -fmessage-length=0 -fmessage-length=0 -
fPIC -o /var/tmp//cc3TMsh8.s
GNU CPP version 3.2.1 (cpplib) (sparc ELF)
GNU C++ version 3.2.1 (sparc-sun-solaris2.8)
compiled by GNU C version 3.2.1.
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1/sparc-
sun-solaris2.8"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../include/c++/3.2.1/
backward"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/include"
ignoring nonexistent directory "/CMC/tools/synopsys/sim/sparcOS5/gcc/gcc-2.6
.3/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../../../sparc-sun-solaris2.8/
include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/lib/gcc-lib/../../sparc-sun-solar
is2.
8/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc-lib/../../include/c++/3.2.1
/usr/local/lib/gcc-lib/../../include/c++/3.2.1/sparc-sun-solaris2.8
/usr/local/lib/gcc-lib/../../include/c++/3.2.1/backward
/usr/local/include
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/include
/usr/include
End of search list.
/usr/ccs/bin/as -V -Qy -s -K PIC -o /var/tmp//ccMksunp.o /var/tmp//cc3TMsh8.
s
/usr/ccs/bin/as: Sun WorkShop 6 99/08/18
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/collect2 -V -G -dy -z text
 -Y
P, /usr/ccs/lib:/usr/lib -Qy -o client.mexsol /usr/local/lib/gcc-lib/sparc-
sun-solaris2.8/3.2.1/crti.o /usr/ccs/lib/values-Xa.o /usr/local/lib/gcc-lib/
sparc-sun-solaris2.8/3.2.1/crtbegin.o -L /opt/matlab13/bin/sol2 -L/CMC/
tools/synopsys/sim/sparcOS5/gcc/gcc-2.6.3/lib/gcc-lib -L/usr/local/lib/gcc-
lib/sparc-sun-solaris2.8/3.2.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/../../.. /var/tmp//ccVGSfa9.o /var/
tmp//ccN1AbMQ.o /var/tmp//ccMksunp.o -M /opt/matlab13/extern/lib/sol2/
mexFunction.map -lmx -lmex -lmat -lstdc++ -lm -lgcc_s -lgcc_s /usr/local/
lib/gcc-lib/sparc-sun-solaris2.8/3.2.1/crtend.o /usr/local/lib/gcc-lib/
sparc-sun-solaris2.8/3.2.1/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.282
make[1]: Leaving directory `/home/fma/Applications/Cmln/FFT/PandR/STL'

[ Post a follow-up to this message ]

If you type:

ldd matlab

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

Fred Ma wrote:
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
>

[ Post a follow-up to this message ]

If you type:

ldd matlab

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

Fred Ma wrote:
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
>

[ Post a follow-up to this message ]

Cheryl Jones wrote:
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.



Cheryl,

"matlab" on our system invokes a very complicated
setup script.  Is there a standardized location
that is used for the binary executable?

I tried ldd on my executable and got the following
output:

ldd client.mexsol
libmx.so =>      /opt/matlab13/extern/lib/sol2/libmx.so
libmex.so =>     /opt/matlab13/bin/sol2/libmex.so
libmat.so =>     /opt/matlab13/extern/lib/sol2/libmat.so
libstdc++.so.5 =>        /opt/gcc/current/lib/libstdc++.so.5
libm.so.1 =>     /usr/lib/libm.so.1
libgcc_s.so.1 =>         /opt/gcc/current/lib/libgcc_s.so.1
libut.so =>      /opt/matlab13/extern/lib/sol2/libut.so
libCrun.so.1 =>  /usr/lib/libCrun.so.1
libc.so.1 =>     /usr/lib/libc.so.1
libdl.so.1 =>    /usr/lib/libdl.so.1
libthread.so.1 =>        /usr/lib/libthread.so.1
libw.so.1 =>     /usr/lib/libw.so.1
/usr/platform/SUNW,Sun-Blade-100/lib/libc_psr.so.1

Would the information about the library version be
embedded in any of these dynamic libraries e.g. newlib,
glibc, etc., version XXXX?  I'm not sure I trust the
idea of guessing based on the path.  For my current
situation, I'm sure cygwin uses newlib, and Alan suspects
that solaris uses their own libc (and I'm confident he's
right).  It would just be much nicer to be absolutely
sure (possibly in other situations).

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

[ Post a follow-up to this message ]

Cheryl Jones wrote:
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.



Cheryl,

"matlab" on our system invokes a very complicated
setup script.  Is there a standardized location
that is used for the binary executable?

I tried ldd on my executable and got the following
output:

ldd client.mexsol
libmx.so =>      /opt/matlab13/extern/lib/sol2/libmx.so
libmex.so =>     /opt/matlab13/bin/sol2/libmex.so
libmat.so =>     /opt/matlab13/extern/lib/sol2/libmat.so
libstdc++.so.5 =>        /opt/gcc/current/lib/libstdc++.so.5
libm.so.1 =>     /usr/lib/libm.so.1
libgcc_s.so.1 =>         /opt/gcc/current/lib/libgcc_s.so.1
libut.so =>      /opt/matlab13/extern/lib/sol2/libut.so
libCrun.so.1 =>  /usr/lib/libCrun.so.1
libc.so.1 =>     /usr/lib/libc.so.1
libdl.so.1 =>    /usr/lib/libdl.so.1
libthread.so.1 =>        /usr/lib/libthread.so.1
libw.so.1 =>     /usr/lib/libw.so.1
/usr/platform/SUNW,Sun-Blade-100/lib/libc_psr.so.1

Would the information about the library version be
embedded in any of these dynamic libraries e.g. newlib,
glibc, etc., version XXXX?  I'm not sure I trust the
idea of guessing based on the path.  For my current
situation, I'm sure cygwin uses newlib, and Alan suspects
that solaris uses their own libc (and I'm confident he's
right).  It would just be much nicer to be absolutely
sure (possibly in other situations).

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

[ Post a follow-up to this message ]

Fred Ma <fma@doe.carleton.ca> writes:
quote:

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


I bet on that one :-)

--
Maurizio Loreti                         [url]http://www.pd.infn.it/~loreti/mlo.html[/ur
l]
Dept. of Physics, Univ. of Padova, Italy              ROT13: [email]ybergv@cq.vasa.vg[/emai
l]

[ Post a follow-up to this message ]

Fred Ma <fma@doe.carleton.ca> writes:
quote:

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


I bet on that one :-)

--
Maurizio Loreti                         [url]http://www.pd.infn.it/~loreti/mlo.html[/ur
l]
Dept. of Physics, Univ. of Padova, Italy              ROT13: [email]ybergv@cq.vasa.vg[/emai
l]

[ Post a follow-up to this message ]

Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
quote:


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



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

[ Post a follow-up to this message ]

Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlinux.pd.infn.it>...
quote:


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



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

[ Post a follow-up to this message ]

fma@doe.carleton.ca (fred ma) writes:
quote:

> Maurizio Loreti <mlo@foobar.it> wrote in message news:<rmwu9vg10l.fsf@mlin
ux.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?


The path, /usr/lib, suggests Solaris; the name suggests the C standard
library (printf, .,.).
quote:

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


Try with ar, nm, objdump or similar programs to examine the innards of
libc; but I bet you have a written documentation somewhere.

--
Maurizio Loreti                         [url]http://www.pd.infn.it/~loreti/mlo.html[/ur
l]
Dept. of Physics, Univ. of Padova, Italy              ROT13: [email]ybergv@cq.vasa.vg[/emai
l]

[ Post a follow-up to this message ]