Re: [go-nuts] Go + c++ library? Moving out of gccgo.

[minux]

On Oct 9, 2013 1:01 PM, <mobiled...@gmail.com> wrote:
>
> For a year I used this solution to be able to use a c++ library
> in my project. I had to use gccgo as only then available solution
> for this case.
if your c++ library can expose a c interface, go 1.2's cgo will do.

alternatively, swig is also supported and it can wrap native c++ interface.
> gccgo + c++ library as a Golang package
> https://groups.google.com/forum/#!searchin/golang-nuts/service/golang-nuts/0PtkEbR-Y7k/yjshat2uJ7IJ
>
> Because gccgo is way behind ver. 1.2 I am wondering it is possible
> to do the same now without gccgo?
>
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Constantine Vasil]

Thank you. I found this tutorial:

http://blog.golang.org/c-go-cgo

Is this all what I need?

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 11:36 AM, Constantine Vasil <ths...@gmail.com> wrote:
> Thank you. I found this tutorial:
> http://blog.golang.org/c-go-cgo
>
> Is this all what I need?

If your C++ library can expose a C interface, then, yes.

Ian

[Constantine Vasil]

Yes this C++ library I am using now has C interface.

I suppose it will much easier if I get rid of SWIG.

[Constantine Vasil]

Ian,

The C implementation of this library is incomplete. I have to use

the C++ one.

From my project I already have the Swig files which I linked with gccgo then.

What it needs to be done to use the gccgo project in Go 1.2?

On Wednesday, October 9, 2013 11:44:23 AM UTC-7, Ian Lance Taylor wrote:

[Dave Cheney]

> Because gccgo is way behind ver. 1.2

[citation needed] please

[Constantine Vasil]

I asked Ian about this:

https://groups.google.com/forum/#!searchin/golang-nuts/gccgo$201.2/golang-nuts/iNX9jpufYqY/Y4CkdWo6TP0J

>> When GCC Go version will be released? There is support only for Go 1 in it. 

>The gccgo release schedule is determined by the GCC release schedule, 
>which is not under our control.  The next release of the GCC 4.8 
>series, 4.8.2, will include full support for Go 1.1.2 (except for the 
>reflect.MakeFunc function).  The first release of the GCC 4.9 series, 
>4.9.0, is planned to include full support for Go 1.2. 

>Ian

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 2:56 PM, Constantine Vasil <ths...@gmail.com> wrote:
>
> The C implementation of this library is incomplete. I have to use
> the C++ one.
>
> From my project I already have the Swig files which I linked with gccgo
> then.

SWIG also works with the GC compiler.

> What it needs to be done to use the gccgo project in Go 1.2?

I'm not sure I understand the question. Are you asking: what does it
take to bring gccgo up to the Go 1.2 release? It will require
importing the 1.2 library and implementing the new a[::] in the
compiler. Possibly a few other things.

I've nearly completed the 1.1.2 work, I will probably get to the 1.2
work fairly soon, but I don't know exactly when.

Ian

[Constantine Vasil]

Ian,

Thank you. It is good to have the gccgo 1.2.

Also it is good to have an alternative because gccgo is lagging. 

To paraphrase my question:

1) I have my project MyLib with the C++ library(TheCppLib) working with gccgo 1.0.

2) it is compiled like this: gccgo -o MyLib_t MyLib_t.go MyLib.o MyLib_wrap.o MyLib_impl.o -L/usr/local/lib -l TheCpp -lstdc++ 

3) then I use it with import  "MyLib_pkg/MyLib" - this was according your instructions for creating gccgo package.

Swig is generation these files:

swig -v -Wall -go -intgosize 64 -gccgo -c++ MyLib.i

MyLib.go,  MyLib_wrap.cxx

Now the question is how to use these in Go 1.2?

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 3:34 PM, Constantine Vasil <ths...@gmail.com> wrote:
>
> To paraphrase my question:
> 1) I have my project MyLib with the C++ library(TheCppLib) working with
> gccgo 1.0.
> 2) it is compiled like this: gccgo -o MyLib_t MyLib_t.go MyLib.o
> MyLib_wrap.o MyLib_impl.o -L/usr/local/lib -l TheCpp -lstdc++
> 3) then I use it with import "MyLib_pkg/MyLib" - this was according your
> instructions for creating gccgo package.
>
> Swig is generation these files:
> swig -v -Wall -go -intgosize 64 -gccgo -c++ MyLib.i
> MyLib.go, MyLib_wrap.cxx
>
> Now the question is how to use these in Go 1.2?

Set up a GOPATH repository in the usual way
(http://blog.golang.org/organizing-go-code). Put your MyLib.i in your
directory under src, but name it MyLib.swig. Use "go build" to build
your program.

Ian

[Constantine Vasil]

I just installed the latest version of Swig - swig-2.0.11.

compiled with make check but Go test examples do not compile - got an error

messages:

checking Examples/go/callback

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go_cpp] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [callback.actionexample] Error 2

checking Examples/go/class

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go_cpp] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [class.actionexample] Error 2

checking Examples/go/constants

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [constants.actionexample] Error 2

checking Examples/go/enum

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go_cpp] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [enum.actionexample] Error 2

checking Examples/go/extend

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go_cpp] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [extend.actionexample] Error 2

checking Examples/go/funcptr

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [funcptr.actionexample] Error 2

checking Examples/go/multimap

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [multimap.actionexample] Error 2

checking Examples/go/pointer

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [pointer.actionexample] Error 2

checking Examples/go/reference

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go_cpp] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [reference.actionexample] Error 2

checking Examples/go/simple

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [simple.actionexample] Error 2

checking Examples/go/template

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go_cpp] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [template.actionexample] Error 2

checking Examples/go/variables

example_gc.c:15 6c: No such file or directory: runtime.h

make[3]: *** [go] Error 1

make[2]: *** [build] Error 2

make[2]: Target `check' not remade because of errors.

make[1]: *** [variables.actionexample] Error 2

make: *** [check-go-examples] Error 2

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 3:58 PM, Constantine Vasil <ths...@gmail.com> wrote:
> I just installed the latest version of Swig - swig-2.0.11.
>
> compiled with make check but Go test examples do not compile - got an error
> messages:
> checking Examples/go/callback
> example_gc.c:15 6c: No such file or directory: runtime.h

Make sure the environment variable GOROOT is set correctly. You don't
need to set it when using the go tool, but the SWIG Makefile invokes
6c directly, and you need it then.

Ian

[Constantine Vasil]

it is:

GOROOT="/usr/local/go"

this is where Go is installed.

If it is only for test example, it does not matter.

Here is my setup:

GOPATH="/home/parallels/mygo"

/home/parallels/mygo/src/MyLib

MyLib.swig

--required by MyLib.swig:

MyLib.cpp  

MyLib.h

I suppose running Swig I will get: 

MyLib.go,  MyLib_wrap.cxx

How to make MyLib a package to be used in other projects?

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 4:24 PM, Constantine Vasil <ths...@gmail.com> wrote:
> it is:
> GOROOT="/usr/local/go"
> this is where Go is installed.

You may need to also set GOARCH and GOOS.

> If it is only for test example, it does not matter.

Yes, it is only for the test example.

> Here is my setup:
> GOPATH="/home/parallels/mygo"
> /home/parallels/mygo/src/MyLib
>
> MyLib.swig
> --required by MyLib.swig:
> MyLib.cpp
> MyLib.h
>
> I suppose running Swig I will get:
> MyLib.go, MyLib_wrap.cxx
>
> How to make MyLib a package to be used in other projects?

go build will do that for you.

Ian

[Constantine Vasil]

With only these files:

MyLib.cpp  MyLib.h  MyLib.swig

I am getting:

can't load package: package MyLib: no buildable Go source files in /home/parallels/mygo/src/MyLib

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 4:52 PM, Constantine Vasil <ths...@gmail.com> wrote:
> With only these files:
> MyLib.cpp MyLib.h MyLib.swig
> I am getting:
> can't load package: package MyLib: no buildable Go source files in
> /home/parallels/mygo/src/MyLib

Sorry, yes, you do need at least a simple .go file, so that the
package has a name.

SWIG doesn't generate the most usable interface, so typically people
write a .go file that presents a friendlier interface on top of what
SWIG generates.

Ian

> On Wednesday, October 9, 2013 4:42:46 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Wed, Oct 9, 2013 at 4:24 PM, Constantine Vasil <ths...@gmail.com>
>> wrote:
>> > it is:
>> > GOROOT="/usr/local/go"
>> > this is where Go is installed.
>>
>> You may need to also set GOARCH and GOOS.
>>
>> > If it is only for test example, it does not matter.
>>
>> Yes, it is only for the test example.
>>
>> > Here is my setup:
>> > GOPATH="/home/parallels/mygo"
>> > /home/parallels/mygo/src/MyLib
>> >
>> > MyLib.swig
>> > --required by MyLib.swig:
>> > MyLib.cpp
>> > MyLib.h
>> >
>> > I suppose running Swig I will get:
>> > MyLib.go, MyLib_wrap.cxx
>> >
>> > How to make MyLib a package to be used in other projects?
>>
>> go build will do that for you.
>>
>> Ian
>

[Constantine Vasil]

I created MyLib.go making it a package:

==========

package MyLib

==========

I am wondering how it will work because Swig will generate 

MyLib.go too.

Anyway I ran the "go build" but now got:

./MyLib.h:2:18: fatal error: string: No such file or directory

compilation terminated.

In MyLib.h I have a reference to: 

// MyLib.h

#include <string>

How to solve this issue?

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 5:07 PM, Constantine Vasil <ths...@gmail.com> wrote:
> I created MyLib.go making it a package:
> ==========
> package MyLib
> ==========
>
> I am wondering how it will work because Swig will generate
> MyLib.go too.
>
> Anyway I ran the "go build" but now got:
> ./MyLib.h:2:18: fatal error: string: No such file or directory
> compilation terminated.
>
> In MyLib.h I have a reference to:
> // MyLib.h
> #include <string>
>
> How to solve this issue?

Oh, sorry, since this is C++ you may need to name your SWIG file
MyLib.swigcxx rather than MyLib.swig, to tell the go tool to use the
C++ compiler. I don't know if that will fix this problem--I don't
know exactly what is happening.

Also you probably need to be using go tip if you aren't already.

Ian

[Constantine Vasil]

I am using the "tip" from Sep 19.

renaming
MyLib.swig

to

MyLib.swigcxx

removed the error messages.

the only thing remained - the MyLib.go I need to create.

This is not working:

============

MyLib.go

============

package MyLib

func main() {

}

============

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 6:46 PM, Constantine Vasil <ths...@gmail.com> wrote:
> I am using the "tip" from Sep 19.
> renaming
> MyLib.swig
> to
> MyLib.swigcxx
>
> removed the error messages.
>
> the only thing remained - the MyLib.go I need to create.
>
> This is not working:
> ============
> MyLib.go
> ============
> package MyLib
>
> func main() {
>
> }
>
> ============

How does it fail?

Naming a function main in a package that is not main seems unusual.

[Constantine Vasil]

OK I created:

MyLib_Test.go 

==================

package MyLib_test

==================

import (

"MyLib"

"testing"

)

func TestMyLib(t *testing.T) {

...

}

==================

now in src/MyLib:

are the following files:

==================

MyLib.cpp  

MyLib.h  

MyLib.swigcxx  

MyLib_test.go

==================

"go build" finishes with no messages, I expected to see 

in /pkg/linux_amd64 the generated library.

"go test -test.v" finishes with error:

# MyLib

./MyLib_test.go:9: import "MyLib" while compiling that package (import cycle)

FAIL MyLib [build failed]

==================

--Constantine

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 7:47 PM, Constantine Vasil <ths...@gmail.com> wrote:
> OK I created:
>
> MyLib_Test.go

Don't use names like _test. The go tool treats those specially; they
are only used for test code.

> import (
> "MyLib"

You are in the mylib package, you shouldn't need to import it.

Ian

[Constantine Vasil]

This special MyLib.go file what it needs to contain? My tough was 

MyLib_Test.go wil do the trick.

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 8:14 PM, Constantine Vasil <ths...@gmail.com> wrote:
>
> This special MyLib.go file what it needs to contain? My tough was
> MyLib_Test.go wil do the trick.

I don't know what MyLib.go needs to contain. It may not need to
contain anything other than a package declaration.

Ian

> On Wednesday, October 9, 2013 7:59:44 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Wed, Oct 9, 2013 at 7:47 PM, Constantine Vasil <ths...@gmail.com>
>> wrote:
>> > OK I created:
>> >
>> > MyLib_Test.go
>>
>> Don't use names like _test. The go tool treats those specially; they
>> are only used for test code.
>>
>> > import (
>> > "MyLib"
>>
>> You are in the mylib package, you shouldn't need to import it.
>>
>> Ian
>

[Constantine Vasil]

MyLib.go now is just this:

==========

MyLib.go

==========

package MyLib

==========

"go build" finishes with no messages. MyGo id not created in 

"pkg" directory

my structure is"

~/mygo/src/MyLib

~/mygo/pkg/lnux_amd64/

Probably there is an explicit way to generate the Swig code

something like this:

swig -v -Wall -go -intgosize 64 -c++ MyLib.swigcxx

--Constantine

[Constantine Vasil]

I ran "go install"  and now I see MyLib.a in:

~/mygo/pkg/lnux_amd64/

Now how to test it is working?

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 8:26 PM, Constantine Vasil <ths...@gmail.com> wrote:
> MyLib.go now is just this:
> ==========
> MyLib.go
> ==========
> package MyLib
> ==========
>
> "go build" finishes with no messages. MyGo id not created in
> "pkg" directory

That is normal. "go build" just builds. "go install" installs in the
pkg directory.

> my structure is"
> ~/mygo/src/MyLib
> ~/mygo/pkg/lnux_amd64/
>
> Probably there is an explicit way to generate the Swig code
> something like this:
>
> swig -v -Wall -go -intgosize 64 -c++ MyLib.swigcxx

That is definitely not the problem.

If you run "go build -x" (or "go install -x") it will show you exactly
what it is doing.

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 8:46 PM, Constantine Vasil <ths...@gmail.com> wrote:
> I ran "go install" and now I see MyLib.a in:
> ~/mygo/pkg/lnux_amd64/
>
> Now how to test it is working?

I guess you'll have to write some code that uses the package.

[Constantine Vasil]

I see also:

linux_amd64/swig/MyLib-MyLib-swigcxx.so

Now I made a test program MyLib_t.go in different directory importing the new MyLib

and calling a function in it (to_utm).

here is "to_utm" definition in my  MyLib.h

Utm_val to_utm(double latitude, double longitude);

go_response =MyLib.To_utm(lat, lon)

Now I got this error:

./MyLib_t: symbol lookup error: /home/parallels/mygo/pkg/linux_amd64/swig/MyLib-MyLib-swigcxx.so: undefined symbol: _Z6to_utmdd

[Ian Lance Taylor]

On Wed, Oct 9, 2013 at 9:04 PM, Constantine Vasil <ths...@gmail.com> wrote:
> I see also:
> linux_amd64/swig/MyLib-MyLib-swigcxx.so
>
> Now I made a test program MyLib_t.go in different directory importing the
> new MyLib
> and calling a function in it (to_utm).
>
> here is "to_utm" definition in my MyLib.h
> Utm_val to_utm(double latitude, double longitude);
>
> go_response =MyLib.To_utm(lat, lon)
>
> Now I got this error:
>
> ./MyLib_t: symbol lookup error:
> /home/parallels/mygo/pkg/linux_amd64/swig/MyLib-MyLib-swigcxx.so: undefined
> symbol: _Z6to_utmdd

Make sure you are using Go tip, even newer than the first 1.2 release
candidate.

Ian

[Constantine Vasil]

What is the most effective way to be sure my Golang installation is up to date

with the latest tip?

[Ibrahim M. Ghazal]

On Thu, Oct 10, 2013 at 7:31 PM, Constantine Vasil <ths...@gmail.com> wrote:
>
> What is the most effective way to be sure my Golang installation is up to date
> with the latest tip?
>

hg pull -u

See also: http://golang.org/doc/install/source

[Constantine Vasil]

Thank you.

[Constantine Vasil]

Ian,

I see that for these kind of projects it is better to use gccgo.

In production environment it is better to use gccgo because it statically

builds executable with no dependencies. I tried to build the project statically

but because it uses C imports, etc. it cannot be build statically.

You  say gccgo 1.2 is almost ready? Where I can get it?

[Ian Lance Taylor]

On Thu, Oct 10, 2013 at 10:27 AM, Constantine Vasil <ths...@gmail.com> wrote:
>
> I see that for these kind of projects it is better to use gccgo.
>
> In production environment it is better to use gccgo because it statically
> builds executable with no dependencies. I tried to build the project
> statically
> but because it uses C imports, etc. it cannot be build statically.

It is true that right now if you use SWIG the go tool will build a
shared library. It is possible to fix that, but it will require some
changes to SWIG (it needs to emit some additional pragmas) and changes
to the go tool to take advantage of that.

If you use cgo, you can build statically, but I understand that you
are using C++ without a C interface so cgo is not an option.

> You say gccgo 1.2 is almost ready? Where I can get it?

I did not mean to imply that gccgo support for Go 1.2 was almost
ready. There is not much work to be done, but I don't know when I
will get to that work. I expect that the future GCC 4.9 release will
include full support for 1.2.

The GCC 4.8.2 release, which will most likely come out next week,
includes full support for Go 1.1.2. If you build gccgo yourself you
can get that support today from the gccgo branch of the GCC
repository, as described at http://golang.org/doc/install/gccgo .

Ian

[Constantine Vasil]

Ian,

>If you use cgo, you can build statically, but I understand that you 
>are using C++ without a C interface so cgo is not an option. 

I use a few functions only from this C++ library. The author suggested I can 

use C wrappers like this:

============================

... however a C wrapper is a possibility.  For example:

interface.cpp:
================================================================
#include "GeographicLib/Geodesic.hpp"

extern "C"
void GeodInverse(double lat1, double lon1, double lat2, double lon2,
                 double *s12, double *azi1, double *azi2) {
    GeographicLib::Geodesic::WGS84.Inverse(lat1, lon1, lat2, lon2,
                                           *s12, *azi1, *azi2);
    return;
}
================================================================

main.c
================================================================
#include <stdio.h>

void GeodInverse(double lat1, double lon1, double lat2, double lon2,
                 double *s12, double *azi1, double *azi2);

int main() {
  double lat1, lon1, lat2, lon2;
  double s12, azi1, azi2;
  scanf("%lf %lf %lf %lf\n", &lat1, &lon1, &lat2, &lon2);
  GeodInverse(lat1, lon1, lat2, lon2, &s12, &azi1, &azi2);
  printf("%.8f %.8f %.3f\n", azi1, azi2, s12);
}
================================================================

Makefile
================================================================
test: main.o interface.o
        g++ -o $@ $^ -lGeographic -Wl,--rpath -Wl,/usr/local/lib
main.o: main.c
        gcc -c $^
interface.o: interface.cpp
        g++ -c $^
================================================================

make test
echo 1 2 3 4 | ./test
45.14416881 45.21398561 313705.445

============================ 

Will this work with cgo?

--Constantine 

[Ian Lance Taylor]

On Thu, Oct 10, 2013 at 10:53 AM, Constantine Vasil <ths...@gmail.com> wrote:
>
>>If you use cgo, you can build statically, but I understand that you
>>are using C++ without a C interface so cgo is not an option.
>
> I use a few functions only from this C++ library. The author suggested I can
> use C wrappers like this:
> ============================
>
> ... however a C wrapper is a possibility. For example:

...

> Will this work with cgo?

Yes, it should. You'll need to declare the C functions in the comment
that precedes the import "C".

Ian

[Constantine Vasil]

Ian,

Thank you. 

Just updated my go installation to:

go version devel +3f38e968e072 Wed Oct 09 13:52:29 2013 -0700 linux/amd64

I need to learn cgo, could you please point me to best resources?

If go to the go, cgo path these questions arise:

1) one of the reasons to use gccgo was the statically linking. 

How to statically link go program now?

2) In my production environment I am setting in one physical machine

several servers. One of them - A. -is waiting for web socket commands from internet.

It fans-out the requests to 3 internal tcp based services B1, B2, B3..

A, B1, B2, B3. are started as "runit" processes. 

My questions:

1) Can I generate static A, B1, B2, B3. with go 1.2 and how? 

A. is not using any external libraries it is pure Go.

B1, B2, B3 will need cgi because they are using external C/C++ libraries. How to generate them to be static? 

2) Right now they were compiled with no external dependencies and used the Go 1.2 run time.

I suppose with static linking each of A, B1, B2, B3. gets its own Go environment.

3) B1, B2, B3 are waiting on tcp port and called from A. If they are residing on same machine

is this the most efficient way A to communicate with  B1, B2, B3? Probably named pipes will be faster? If so how to implement them with named pipes?

[Ian Lance Taylor]

On Thu, Oct 10, 2013 at 11:22 AM, Constantine Vasil <ths...@gmail.com> wrote:
>
> I need to learn cgo, could you please point me to best resources?

http://blog.golang.org/c-go-cgo
http://golang.org/cmd/cgo/

> If go to the go, cgo path these questions arise:
>
> 1) one of the reasons to use gccgo was the statically linking.
> How to statically link go program now?

Something along the lines of:

go build -ldflags -extldflags=-static

> 2) In my production environment I am setting in one physical machine
> several servers. One of them - A. -is waiting for web socket commands from
> internet.
> It fans-out the requests to 3 internal tcp based services B1, B2, B3..
> A, B1, B2, B3. are started as "runit" processes.
>
> My questions:
> 1) Can I generate static A, B1, B2, B3. with go 1.2 and how?
> A. is not using any external libraries it is pure Go.
> B1, B2, B3 will need cgi because they are using external C/C++ libraries.
> How to generate them to be static?

See above.

> 2) Right now they were compiled with no external dependencies and used the
> Go 1.2 run time.
> I suppose with static linking each of A, B1, B2, B3. gets its own Go
> environment.
>
> 3) B1, B2, B3 are waiting on tcp port and called from A. If they are
> residing on same machine
> is this the most efficient way A to communicate with B1, B2, B3? Probably
> named pipes will be faster? If so how to implement them with named pipes?

I don't know. I would probably try Unix sockets.

Ian

[Constantine Vasil]

Ian,

I installed gcc, g++, gccgo 4.8.1 too

running old script (for 4.7.3) to compile my project now I got the following

message:

dbgen_t.go:(.text+0xde98b): undefined reference to `strings..import'

The script is:

====

gccgo dbgen_t.go -o dbgen_t  -I$HOME/mygo/pkg/gccgo money.o dbgen.o  -L$HOME/mygo/pkg/gccgo/github.com/jmhodges -llevigo -L$HOME/mygo/pkg/gccgo/github.com/torbit -lcdb  -L$HOME/mygo/pkg/gccgo/code.google.com/p/go.net -lwebsocket -L$HOME/mygo/pkg/gccgo/code.google.com/p/leveldb-go/leveldb -lmemdb -ldb /usr/local/lib/libleveldb.a /usr/local/lib/libsnappy.a   $HOME/mygo/pkg/gccgo/geoconvert_pkg/geoconvert.o $HOME/mygo/pkg/gccgo/geoconvert_pkg/geoconvert_wrap.o $HOME/mygo/pkg/gccgo/geoconvert_pkg/geoconvert_impl.o -I$HOME/mygo/pkg/gccgo /usr/local/lib/libGeographic.a -lstdc++

====

[Ian Lance Taylor]

On Thu, Oct 10, 2013 at 2:39 PM, Constantine Vasil <ths...@gmail.com> wrote:
>
> I installed gcc, g++, gccgo 4.8.1 too
> running old script (for 4.7.3) to compile my project now I got the following
> message:
> dbgen_t.go:(.text+0xde98b): undefined reference to `strings..import'
>
> The script is:
> ====
> gccgo dbgen_t.go -o dbgen_t -I$HOME/mygo/pkg/gccgo money.o dbgen.o
> -L$HOME/mygo/pkg/gccgo/github.com/jmhodges -llevigo
> -L$HOME/mygo/pkg/gccgo/github.com/torbit -lcdb
> -L$HOME/mygo/pkg/gccgo/code.google.com/p/go.net -lwebsocket
> -L$HOME/mygo/pkg/gccgo/code.google.com/p/leveldb-go/leveldb -lmemdb -ldb
> /usr/local/lib/libleveldb.a /usr/local/lib/libsnappy.a
> $HOME/mygo/pkg/gccgo/geoconvert_pkg/geoconvert.o
> $HOME/mygo/pkg/gccgo/geoconvert_pkg/geoconvert_wrap.o
> $HOME/mygo/pkg/gccgo/geoconvert_pkg/geoconvert_impl.o -I$HOME/mygo/pkg/gccgo
> /usr/local/lib/libGeographic.a -lstdc++
> ====

Did you recompile money.o and dbgen.o with the newly installed gccgo?
Make sure that all existing .o and .a files are recompiled with the
new version of gccgo.

Ian

[Constantine Vasil]

yes, I did

The message is for the main function during link phase

dbgen_t.o: In function `__go_init_main':

dbgen_t.go:(.text+0xde98b): undefined reference to `strings..import'

collect2: error: ld returned 1 exit status

[Ian Lance Taylor]

On Thu, Oct 10, 2013 at 3:10 PM, Constantine Vasil <ths...@gmail.com> wrote:
> yes, I did
>
> The message is for the main function during link phase
> dbgen_t.o: In function `__go_init_main':
> dbgen_t.go:(.text+0xde98b): undefined reference to `strings..import'
> collect2: error: ld returned 1 exit status

Sorry, no idea. I'm fairly sure that they only way this could
possibly happen is if you are somehow mixing an old installation and a
new one.

For example, this could happen if the compiler is seeing the old
packages but the linker is seeing the new ones.

Ian

[Constantine Vasil]

I think so. Will recompile all imported packages too.

[Constantine Vasil]

The leveldb-go/leveldb package cannot compile with gccgo:

go get -compiler=gccgo code.google.com/p/leveldb-go/leveldb

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 8:15 AM, Constantine Vasil <ths...@gmail.com> wrote:
> The leveldb-go/leveldb package cannot compile with gccgo:
> go get -compiler=gccgo code.google.com/p/leveldb-go/leveldb

You're right, clearly nobody tries this. Thanks for tackling it.

Should be fixed by https://codereview.appspot.com/14535048 which I've
mailed out for review.

[Constantine Vasil]

what I need to do to advance with my project?

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 8:58 AM, Constantine Vasil <ths...@gmail.com> wrote:
> what I need to do to advance with my project?

You seem to be trying several things at once and I'm not really sure
what to advise.

I expect the patch I wrote will be submitted in the next few hours, or
you can patch it into your local copy of the sources by installing the
codereview extension
(http://golang.org/doc/contribute.html#Code_review) and running "hg
clpatch 14535048".

Ian

[Constantine Vasil]

Ian,

Thank you for the patch. I applied the patch. 

it is now installed in:

/mygo/pkg/gccgo_linux_amd64

before it was in: 

/mygo/pkg/gccgo 

 

it this correct behavior?

--Constantine

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 9:34 AM, Constantine Vasil <ths...@gmail.com> wrote:
>
> Thank you for the patch. I applied the patch.
>
> it is now installed in:
> /mygo/pkg/gccgo_linux_amd64
> before it was in:
> /mygo/pkg/gccgo
>
> it this correct behavior?

Yes.

Ian

[Constantine Vasil]

I changed all references to /mygo/pkg/gccgo_linux_amd64

and now the project compiles with gccgo 1.1.2

[Constantine Vasil]

Successfuly compiled with gccgo, runs locally.

When deployed to the server got this error:

WebServer: error while loading shared libraries: libgo.so.3: cannot open shared object file: No such file or directory

Here is how it is linked:

gccgo -o WebServer -I$HOME/mygo/pkg/gccgo_linux_amd64 WebServer.o  -L$HOME/mygo/pkg/gccgo_linux_amd64/code.google.com/p/go.net -lwebsocket  $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert.o $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_wrap.o $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_impl.o -I$HOME/mygo/pkg/gccgo_linux_amd64 /usr/local/lib/libGeographic.a -lstdc++

How to link it statically?

--Constantine

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 2:42 PM, Constantine Vasil <ths...@gmail.com> wrote:
> Successfuly compiled with gccgo, runs locally.
> When deployed to the server got this error:
> WebServer: error while loading shared libraries: libgo.so.3: cannot open
> shared object file: No such file or directory
>
> Here is how it is linked:
> gccgo -o WebServer -I$HOME/mygo/pkg/gccgo_linux_amd64 WebServer.o
> -L$HOME/mygo/pkg/gccgo_linux_amd64/code.google.com/p/go.net -lwebsocket
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert.o
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_wrap.o
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_impl.o
> -I$HOME/mygo/pkg/gccgo_linux_amd64 /usr/local/lib/libGeographic.a -lstdc++
>
> How to link it statically?

On the link command line that you show, pass the -static option to
link fully statically.

Or pass the -static-libgo option to link just libgo statically.

Ian

[Constantine Vasil]

with:

gccgo -o WebServer -I$HOME/mygo/pkg/gccgo_linux_amd64 WebServer.o  -L$HOME/mygo/pkg/gccgo_linux_amd64/code.google.com/p/go.net -lwebsocket  $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert.o $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_wrap.o $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_impl.o -I$HOME/mygo/pkg/gccgo_linux_amd64 /usr/local/lib/libGeographic.a -lstdc++ -static

got:

/usr/lib/gcc/x86_64-linux-gnu/4.8/libgo.a(net.o): In function `net.lookupPort':

(.text+0x3e52): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 3:14 PM, Constantine Vasil <ths...@gmail.com> wrote:
> with:
> gccgo -o WebServer -I$HOME/mygo/pkg/gccgo_linux_amd64 WebServer.o
> -L$HOME/mygo/pkg/gccgo_linux_amd64/code.google.com/p/go.net -lwebsocket
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert.o
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_wrap.o
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_impl.o
> -I$HOME/mygo/pkg/gccgo_linux_amd64 /usr/local/lib/libGeographic.a -lstdc++
> -static
>
> got:
> /usr/lib/gcc/x86_64-linux-gnu/4.8/libgo.a(net.o): In function
> `net.lookupPort':
> (.text+0x3e52): warning: Using 'getaddrinfo' in statically linked
> applications requires at runtime the shared libraries from the glibc version
> used for linking

Yes. This has nothing to do with Go. It is true for any statically
linked program on GNU/Linux that calls getaddrinfo.

[Constantine Vasil]

>Yes.  This has nothing to do with Go.  It is true for any statically 
>linked program on GNU/Linux that calls getaddrinfo. 

How to solve it please? This is something new.

Also I tried the second suggestion:

gccgo -o WebServer -I$HOME/mygo/pkg/gccgo_linux_amd64 WebServer.o  -L$HOME/mygo/pkg/gccgo_linux_amd64/code.google.com/p/go.net -lwebsocket  $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert.o $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_wrap.o $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_impl.o -I$HOME/mygo/pkg/gccgo_linux_amd64 /usr/local/lib/libGeographic.a -lstdc++ -static-libgo 

but this time got another error:

/usr/bin/ld: WebServer: hidden symbol `__wrap_pthread_create' in /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(generic-morestack-thread.o) is referenced by DSO

/usr/bin/ld: final link failed: Bad value

collect2: error: ld returned 1 exit status

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 3:27 PM, Constantine Vasil <ths...@gmail.com> wrote:
>>Yes. This has nothing to do with Go. It is true for any statically
>>linked program on GNU/Linux that calls getaddrinfo.
>
> How to solve it please? This is something new.

I repeat: this has nothing to do with Go.


Also, it is just a warning.

> warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

It means that the glibc shared libraries must be available on the
system at the time that the program is run.

> Also I tried the second suggestion:
> gccgo -o WebServer -I$HOME/mygo/pkg/gccgo_linux_amd64 WebServer.o
> -L$HOME/mygo/pkg/gccgo_linux_amd64/code.google.com/p/go.net -lwebsocket
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert.o
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_wrap.o
> $HOME/mygo/pkg/gccgo_linux_amd64/geoconvert_pkg/geoconvert_impl.o
> -I$HOME/mygo/pkg/gccgo_linux_amd64 /usr/local/lib/libGeographic.a -lstdc++
> -static-libgo
>
> but this time got another error:
> /usr/bin/ld: WebServer: hidden symbol `__wrap_pthread_create' in
> /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a(generic-morestack-thread.o) is
> referenced by DSO
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status

That is strange. This is a GNU ld specific warning, but I'm not sure
what causes it. One possible way to avoid this might be to also use
the -static-libgcc option. I don't know.

[Constantine Vasil]

I see this warning just says to be sure to have same version of libc on the server.

It is OK.

The packages compiled with -static and deployed on the server work just fine.

Thank you very much!

--Constantine

P.S. does it make sense to use the gccgo on gcc 4.8.1 from this location? Is it suitable for production?

svn checkout svn://gcc.gnu.org/svn/gcc/branches/gccgo gccgo

[Ian Lance Taylor]

On Fri, Oct 11, 2013 at 4:12 PM, Constantine Vasil <ths...@gmail.com> wrote:
>
> P.S. does it make sense to use the gccgo on gcc 4.8.1 from this location? Is
> it suitable for production?
>
> svn checkout svn://gcc.gnu.org/svn/gcc/branches/gccgo gccgo

Yes, this should be fine.

Ian