compiling g++ 3.2.3

compiling g++ 3.2.3

[Tan-Long Phan]

Hi

I'm trying to configure and install the gcc 3.2.3 on AIX platform (OS 4.3).
After configuring the gcc with option --enable-threads=posix, and installing
the compiler, when I check the compiler by executing: g++ -v, it shows the
following messages:

Configured with: ../gcc-3.2.3/configure --enable-threads=posix
--prefix=/cae/3rdpartty
Thread model: aix
gcc version 3.2.3

Is it supposed to show Thread model: posix instead of aix. After this, when
I'm using functions sched_get_priority_min, sched_get_priority_max from
thread, it returns error: "Function not implemented POSIX"

Am I missing something when installing gcc 3.2.3 on the AIX platform? 

Thanks & Regards

Long

Re: compiling g++ 3.2.3

[Ed Schouten]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Thu, 2004-07-08 at 11:20 -0400, Tan-Long Phan wrote:
> Am I missing something when installing gcc 3.2.3 on the AIX platform?

Could it be possible that AIX isn't compatible with POSIX threads, or
shouldn't that be a problem?

Yours,
-- 
 Ed Schouten
 <edschouten@il.fontys.nl>
 GnuPG key: gpg --keyserver pgp.mit.edu --recv-keys 0xD6A1AF3E

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

unsuscribe

[Sylvain Becker]

Re: compiling g++ 3.2.3

[David Edelsohn]

>>>>> Tan-Long Phan writes:

Phan> This is the first time I'm porting my code from Linux to AIX, thankyou very
Phan> much for your greate support. I still have another problem porting my
Phan> software to AIX. On Linux, I use ioctl to get the hardware address  of my
Phan> network card : ioctl(mySocket, SIOCGIFHWADDR, (char *)wInfo); and the
Phan> hardware address is returned in wInfo->ifr_hwaddr.sa_data[0] (wInfo is a
Phan> pointer to ifreq structure). On AIX, ifr_hwaddr is not part of ifreq
Phan> anymore, is there another way to get the hardware address on AIX

	Sorry, but this mailinglist is for help with GCC on various
platforms, not general questions about porting to AIX.

David

RE: compiling g++ 3.2.3

[Tan-Long Phan]

Hi guys

This is the first time I'm porting my code from Linux to AIX, thankyou very
much for your greate support. I still have another problem porting my
software to AIX. On Linux, I use ioctl to get the hardware address  of my
network card : ioctl(mySocket, SIOCGIFHWADDR, (char *)wInfo); and the
hardware address is returned in wInfo->ifr_hwaddr.sa_data[0] (wInfo is a
pointer to ifreq structure). On AIX, ifr_hwaddr is not part of ifreq
anymore, is there another way to get the hardware address on AIX

Thanks & Regards

Long Phan


-----Original Message-----
From: David Edelsohn [mailto:dje@watson.ibm.com]
Sent: Monday, June 21, 2004 3:54 PM
To: lrtaylor@micron.com; longp@CAE.COM
Cc: gcc-help@gcc.gnu.org
Subject: Re: compiling g++ 3.2.3 


>>>>> lrtaylor  writes:

Lyle> Actually, AIX has three library concepts or types on the Power
platform
Lyle> rather than the traditional two.  There are static libraries (which
are
Lyle> .a archive files just like those you see on many other UNIX
platforms),
Lyle> shared libraries (which are special .a archive files that are built in
Lyle> such as way as to be linked in dynamically at run time - as opposed to
Lyle> statically like normal .a files are), and shared objects (the
Lyle> traditional .so file).  The terms "shared library" and "shared object"
Lyle> are not synonymous on AIX like they essentially are on many other UNIX
Lyle> platforms.

	AIX treats shared libraries (an archive of shared objects) and
shared objects the same.  An executable or shared object depends on a
shared object archive member of the shared library.  The shared library
may contain both shared objects and non-shared objects.

	".so" file extension and shared object are completely separate and
orthogonal concepts.  On AIX, a shared object can have any file extension.
The AIX linker only recognizes certain extensions when one does not refer
to the entire filename (e.g., -lfoo).  On AIX, ".so" file extension
normally corresponds to shared objects with the additional semantics of
runtime linking for compatibility with other Unixes.  A shared object can
be named shr.o or libfoo.a or libbar.so, for example.  The ".so" file
extension is a convention on AIX but does not itself imply any different
semantics. 

Lyle> AIX links to libraries ending in .a by default.  This does not mean
that
Lyle> it is linking statically by default, unless the library it finds is a
Lyle> static library. In order to tell the linker to link to .so files by
Lyle> default, you need to specify the -brtl option (for run-time linking as
Lyle> they call it).  That's the option that is passed to IBM's VisualAge
Lyle> compiler, so I don't know if GCC recognizes it.  If it doesn't, then
you
Lyle> might try '-Wl,-brtl'.

	-brtl tells the linker to look for ".so" file extension as well
and changes the semantics to runtime linking, but ".so" does not mean
runtime linking unless the developer follows the naming conventions.

	GCC does not require runtime linking.  GCC libstdc++ is built
runtime linking ready (with -G option), but applications do not link using
-brtl by default.  It only helps in corner cases (like user overriding
new[] operator). 

	One can add -Wl,-brtl to GCC link line and it will work, but it is
better to avoid those semantics unless needed.

	The AIX command

$ dump -H <filename>

prints the shared library dependencies and will show if the library was
linked shared.

	Bottom line: ".a" file extension does not mean static linking.

David

Re: compiling g++ 3.2.3

[David Edelsohn]

>>>>> lrtaylor  writes:

Lyle> Actually, AIX has three library concepts or types on the Power platform
Lyle> rather than the traditional two.  There are static libraries (which are
Lyle> .a archive files just like those you see on many other UNIX platforms),
Lyle> shared libraries (which are special .a archive files that are built in
Lyle> such as way as to be linked in dynamically at run time - as opposed to
Lyle> statically like normal .a files are), and shared objects (the
Lyle> traditional .so file).  The terms "shared library" and "shared object"
Lyle> are not synonymous on AIX like they essentially are on many other UNIX
Lyle> platforms.

	AIX treats shared libraries (an archive of shared objects) and
shared objects the same.  An executable or shared object depends on a
shared object archive member of the shared library.  The shared library
may contain both shared objects and non-shared objects.

	".so" file extension and shared object are completely separate and
orthogonal concepts.  On AIX, a shared object can have any file extension.
The AIX linker only recognizes certain extensions when one does not refer
to the entire filename (e.g., -lfoo).  On AIX, ".so" file extension
normally corresponds to shared objects with the additional semantics of
runtime linking for compatibility with other Unixes.  A shared object can
be named shr.o or libfoo.a or libbar.so, for example.  The ".so" file
extension is a convention on AIX but does not itself imply any different
semantics. 

Lyle> AIX links to libraries ending in .a by default.  This does not mean that
Lyle> it is linking statically by default, unless the library it finds is a
Lyle> static library. In order to tell the linker to link to .so files by
Lyle> default, you need to specify the -brtl option (for run-time linking as
Lyle> they call it).  That's the option that is passed to IBM's VisualAge
Lyle> compiler, so I don't know if GCC recognizes it.  If it doesn't, then you
Lyle> might try '-Wl,-brtl'.

	-brtl tells the linker to look for ".so" file extension as well
and changes the semantics to runtime linking, but ".so" does not mean
runtime linking unless the developer follows the naming conventions.

	GCC does not require runtime linking.  GCC libstdc++ is built
runtime linking ready (with -G option), but applications do not link using
-brtl by default.  It only helps in corner cases (like user overriding
new[] operator). 

	One can add -Wl,-brtl to GCC link line and it will work, but it is
better to avoid those semantics unless needed.

	The AIX command

$ dump -H <filename>

prints the shared library dependencies and will show if the library was
linked shared.

	Bottom line: ".a" file extension does not mean static linking.

David

RE: compiling g++ 3.2.3

[lrtaylor]

Actually, AIX has three library concepts or types on the Power platform
rather than the traditional two.  There are static libraries (which are
.a archive files just like those you see on many other UNIX platforms),
shared libraries (which are special .a archive files that are built in
such as way as to be linked in dynamically at run time - as opposed to
statically like normal .a files are), and shared objects (the
traditional .so file).  The terms "shared library" and "shared object"
are not synonymous on AIX like they essentially are on many other UNIX
platforms.

AIX links to libraries ending in .a by default.  This does not mean that
it is linking statically by default, unless the library it finds is a
static library. In order to tell the linker to link to .so files by
default, you need to specify the -brtl option (for run-time linking as
they call it).  That's the option that is passed to IBM's VisualAge
compiler, so I don't know if GCC recognizes it.  If it doesn't, then you
might try '-Wl,-brtl'.

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of David Edelsohn
Sent: Monday, June 21, 2004 1:10 PM
To: Tan-Long Phan
Cc: gcc-help@gcc.gnu.org
Subject: Re: compiling g++ 3.2.3 

>>>>> Tan-Long Phan writes:

Phan> I'm compiling c++ code under AIX 4.3, I would like to link dynamic
library
Phan> (.so) with another one (.so). What linker option should I use to
link
Phan> differents (extension .so) libraries together? if I put -l option
followed
Phan> by the library name it would link statically.

	I am a little confused by your description.  You are trying to
create a shared library on AIX that depends on another shared library?
Adding the dependent shared library on the link line creating the new
shared library should work.  What do you mean by "it would link
statically"?  Adding the library to the link line will not include the
code from the old library in the new one.

	Are you sure that the libraries you created are shared objects?
AIX shared objects normally have file extension ".a", not ".so", and
normally are an *ARCHIVE* of shared objects, not a bare shared object,
but
AIX will deal with either.  AIX ignores shared libraries with ".so"
extension unless the AIX linker -G (to create) / -brtl (to use) options
are used.  If you are forcing the AIX linker to use the files with the
incorrect file extensions, the linker may be using different files than
you expect or you may be invoking different linker semantics than you
intend.

David

Re: compiling g++ 3.2.3

[David Edelsohn]

>>>>> Tan-Long Phan writes:

Phan> I'm compiling c++ code under AIX 4.3, I would like to link dynamic library
Phan> (.so) with another one (.so). What linker option should I use to link
Phan> differents (extension .so) libraries together? if I put -l option followed
Phan> by the library name it would link statically.

	I am a little confused by your description.  You are trying to
create a shared library on AIX that depends on another shared library?
Adding the dependent shared library on the link line creating the new
shared library should work.  What do you mean by "it would link
statically"?  Adding the library to the link line will not include the
code from the old library in the new one.

	Are you sure that the libraries you created are shared objects?
AIX shared objects normally have file extension ".a", not ".so", and
normally are an *ARCHIVE* of shared objects, not a bare shared object, but
AIX will deal with either.  AIX ignores shared libraries with ".so"
extension unless the AIX linker -G (to create) / -brtl (to use) options
are used.  If you are forcing the AIX linker to use the files with the
incorrect file extensions, the linker may be using different files than
you expect or you may be invoking different linker semantics than you
intend.

David