Clarification

Clarification

[Jeffrey A Law]

A minor clarification on the bootstrap requirement.

It applies to code generation and optimizer chagnes.  It does not apply
to the front-ends & cpp.  Hopefully we will not ever need to apply it to
the front-ends & cpp.

The idea is not to stop develoment, but to try and stabilize changes as they
go in so we can get a better picture of a reasonable egcs-1.2 schedule.



jeff

Clarification

[Jeffrey A Law]

A minor clarification on the bootstrap requirement.

It applies to code generation and optimizer chagnes.  It does not apply
to the front-ends & cpp.  Hopefully we will not ever need to apply it to
the front-ends & cpp.

The idea is not to stop develoment, but to try and stabilize changes as they
go in so we can get a better picture of a reasonable egcs-1.2 schedule.



jeff

Clarification

[Damian Minihan]

Hi,

We are trying to use egcs 2.95.2 on our development, but I was having
trouble linking. I noticed the following on the Using and Porting the GNU
Compiler Collection (GCC) webpage in the Interoperation section:

GNU C++ does not do name mangling in the same way as other C++ compilers.
This means that object files compiled with one compiler cannot be used with
another.

Is this true of version g++ 2.95.2. We are developing on a solaris 8 box
using Orbix 3. The Orbix is precompiled using Sun WS 4.2. We are only
supplied the prebuilt libraries. Does this mean that we cannot use g++, or
is there a way around this?

Thanks in advance,
Damian


> Damian Minihan
> Research & Development
> 
> Computer Answers International Limited
> 9 The Courtyard, Warwick Road, Solihull 
> West Midlands. B91 3DA. United Kingdom
> 
> Tel:       +44 (0)121 703 0300
> Fax:      +44 (0)121 703 0399
> E-mail:   Damian.Minihan@compans.com
> Website: www.compans.com
> 
> 

Re: Clarification

[Alexandre Oliva]

On Jul  6, 2000, Damian Minihan <damian.minihan@compans.com> wrote:

> GNU C++ does not do name mangling in the same way as other C++ compilers.

Correct.  There's no standard C++ ABI as of GCC 2.95.2.  A
cross-platform C++ ABI is currently being specified and developed,
which will allow linking of object files generated by multiple C++
compilers.  Until this work is finished, you'll have to compile all
your C++ code with the same C++ compiler.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Clarification

[Neelakanth]

Sometime ago, Alexandre Oliva said:
> Correct.  There's no standard C++ ABI as of GCC 2.95.2.  A
> cross-platform C++ ABI is currently being specified and developed,
> which will allow linking of object files generated by multiple C++
> compilers.  Until this work is finished, you'll have to compile all
> your C++ code with the same C++ compiler.
> 
Where can I find more info about this  cross-platform C++ ABI ?

-neelakanth

-- 
______________________
Neelakanth Nadgir
(neelakanth @ gnu.org)
______________________
http://www.gnu.org

Re: Clarification

[Martin v. Loewis]

> Where can I find more info about this  cross-platform C++ ABI ?

Please have a look at

http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html

Regards,
Martin

Re: Clarification

[Philipp Thomas]

* Alexandre Oliva (aoliva@redhat.com) [20000706 13:04]:

> compilers.  Until this work is finished, you'll have to compile all
> your C++ code with the same C++ compiler.

You might add to that "and all compilers involved comply to that C++ ABI"
;-)

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

Clarification

[Sangwan, Vikas (CORP, GEITC)]

Hello All,

	I am trying to build a shared library from a set of '.o's.  Reason
being, trying to use JNI to invoke some API code and it expects a shared
library.  

What have I done so far ?

	Earler I had static libraries with me i.e the '.a's, so used "ar -x
<file.a>" and extracted out the ..o's.  However I am trying to build a
shared object on Solaris using the folloiwiing command but there are a lof
external reference symbols thrown back.

	Text relocation remains                         referenced
    against symbol                  offset      in file
<unknown>                           0x14        tcp_scb.o
<unknown>                           0x18        tcp_scb.o
<unknown>                           0x30        tcp_scb.o
<unknown>                           0x34        tcp_scb.o
<unknown>                           0x3c        tcp_scb.o
<unknown>                           0x40        tcp_scb.o
<unknown>                           0x69c       tcp_scb.o
<unknown>                           0x6a0       tcp_scb.o
inet_ntoa                           0x790       tcp_scb.o
gethostbyaddr                       0x744       tcp_scb.o
strdup                              0x6e0       tcp_scb.o
GuStrMake                           0x6c8       tcp_scb.o
com_addr_tcpaddr_str                0x694       tcp_scb.o
strcpy                              0x620       tcp_scb.o
strcpy                              0x674       tcp_scb.o
strcpy                              0x7b4       tcp_scb.o
GuComAddrFree                       0x4d4       tcp_scb.o
ComRemoteAddr                       0x43c       tcp_scb.o
ComTcpSetAddr                       0x3b8       tcp_scb.o

	If any of you could shared your experiences, it will ge great.

Rgds
Vikas

Re: Clarification

[Alexandre Oliva]

On Feb 13, 2001, "Sangwan, Vikas (CORP, GEITC)" <Vikas.Sangwan@geind.ge.com> wrote:

> I am trying to build a shared library from a set of '.o's.

Compile with -fPIC, otherwise Sun's linker will complain unless you
run gcc with -mimpure-text.  The latter will result in dynamic
libraries, but not shared libraries (in the sense that their memory
pages won't be shareable across multiple processes, because they'd
need relocations).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me