[Bug go/54918] New: libgo.so.0 is not runtime compatible between gcc-4.6.2 and gcc-4.7.x

[gafton at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54918



 Bug #: 54918

   Summary: libgo.so.0 is not runtime compatible between gcc-4.6.2

and gcc-4.7.x

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

ReportedBy: gaf...@gmail.com





gcc-4.6.2 shipped a libgo.so.0.0.0 runtime library.



Compiling a simple hello world binary against that libgo worked okay:



bash$ cat hello.go

package main

import "fmt"

func main() {

  fmt.Println("Hello, world")

}

bash$ gccgo -o hello hello.go

bash$ ./hello

Hello, world



When  the gcc runtime is updated on the system to gcc-4.7.2, the previouslt

compiled binary against the gcc-4.6.2 libgo.so.0 no longer works:



bash$ ./hello

./hello: symbol lookup error: ./hello: undefined symbol: libgo_os.os.Envs



Clearly the two libgo.so.0.0.0 libraries are not compatible between gcc-4.6.x

and gcc-4.7.x - as such, the soname versioning should reflect that.

[Bug go/54918] libgo.so.0 is not runtime compatible between gcc-4.6.2 and gcc-4.7.x

[gafton at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54918



--- Comment #2 from Cristian Gafton  2012-10-15 
17:53:46 UTC ---

(In reply to comment #1)

> incompatible as in missing symbols or in incompatible behavior between

> different

> symbols?



I have only run across missing symbols, but it looks like none of the changes

in the libgo library have been dressed with any sort of symbol versioning, so

there could also be some incompatible behaviour changes. I have not studied the

libgo source enough to make that determination though;  the missing symbols

make it hard to test older binaries to check for behavioral changes.