by d.wright.dev:

What steps will reproduce the problem?

This is an issue that implies that there might be something funny going on with 8l
(illegal code points? newlines? non printing characters?), although the exported symbols
are printed by nm.

When exporting function symbols using the //export <symbolname> comment syntax on
Mountain Lion, they cannot reliably be found by dlsym() when invoked upon the executable
from within the program itself. 

The behavior seems to vary by symbol name. If the first character of the export is
several letters off in alphabetical sequence from the last one, dlsym() finds the
symbol. This is pretty inconvenient and obviously not the main issue.

see: dlbug_fail.go, dlbug_pass.go


What is the expected output?

> go run dlbug_fail.go

symbol:IMPWindowResize found
symbol:IMPDrawRect found
symbol:IMPInitWithFrame found
symbol:IMPIsOpaque found

What do you see instead?

symbol:IMPWindowResize found
symbol:IMPDrawRect error: dlsym(RTLD_DEFAULT, IMPDrawRect): symbol not found
symbol:IMPInitWithFrame found
symbol:IMPIsOpaque error: dlsym(RTLD_DEFAULT, IMPIsOpaque): symbol not found

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

OS X 10.8.1 (12B19)

Which version are you using?  (run 'go version')

go version go1.0.2

Please provide any additional information below.

If I could make a suggestion about resource allocation: not being able to use cgo from
within gotest prevents integration of regression testing on this sort of issue. It's
probably worth the time to fix that. The first thing I tried to do before submitting a
report was to package these files as tests. 

Also, "go run" treats files named *_test.go as tests and then fails if tests
aren't found.

I'll file these suggestions as separate bugs.

Attachments:

1. dlbug_fail.go (1371 bytes)
2. dlbug_pass.go (1371 bytes)