Update dropdown.go to compile to lib.so

[SeRj-ThuramS]

Fixing a bug for compiling into a library

2024.06.17 10:13:00 go(build)(error): # /tmp/go-build4195759871/b113/librtl-tview.so panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x51de66]

goroutine 1 [running]: cmd/link/internal/loader.(Loader).SymSize(0x1?, 0x0?) cmd/link/internal/loader/loader.go:815 +0x46 cmd/link/internal/ld.(pclntab).generatePctab.func1(0x0) cmd/link/internal/ld/pcln.go:467 +0x56 cmd/link/internal/ld.(pclntab).generatePctab(0xc000c46f40, 0xc000124200, {0xc001724000, 0x4f3, 0x1?}) cmd/link/internal/ld/pcln.go:490 +0x39f cmd/link/internal/ld.(Link).pclntab(0xc000124200, {0xc001720000?, 0xc0000126e0?, 0xf?}) cmd/link/internal/ld/pcln.go:804 +0x1ad cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0xc000012549, 0x1, 0x1}, ...}) cmd/link/internal/ld/main.go:412 +0x175c main.main() cmd/link/main.go:72 +0xdfb

[rivo]

I think this change makes sense in general. (I think this weird construct originates in a misunderstanding of loop closures on my part.)

However, can you please explain how this leads to a nil pointer exception in your library? The stack trace you posted doesn't reference any tview code.

[SeRj-ThuramS]

I assemble your package like this: sudo go install -linkshared -ldflags="-s -w" -buildmode=shared ${pkg}

Most likely this happens because you are passing variable to the function and do not use it anywhere

1 func (d *DropDown) SetOptions(texts []string, selected func(text string, index int)) *DropDown {
2   d.list.Clear()
3   d.options = nil
4        for index, text := range texts {
5       func(t string, i int) {
6           d.AddOption(text, nil)
7       }(text, index)
8   for _, text := range texts {
9       d.AddOption(text, nil)
10  }
11  d.selected = selected
12  return d

5 func(t string, i int) { In line 5 the argument is i

*golang compiler does not allow leaving unused variables

[rivo]

golang compiler does not allow leaving unused variables

It does not matter in this case. Function arguments can go unused without the compiler complaining. It hasn't complained about this code in 7 years. ;-)

It would also not cause a "nil pointer dereference" or if it did, that would be quite a confusing error message. A quick Google search suggests that the -linkshared and -buildmode=shared combination is not stable and may not even be supported with modules. But I know too little about this to be able to tell.

Anyway, I assume you have tried to make this change locally first, and your command worked afterwards?

[SeRj-ThuramS]

Yes. That's right. The size of the finished libraries is very important for the project. Therefore, the decision was made to use dynamic linking. Your module simplifies the development of a tui control interface. Thank you :)

[rivo]

I merged this because the change makes sense in general.

I was trying to find out some more about how this was related to your dynamic library issue but I'm having trouble understanding your explanations.

Anyway, I hope this merge helps you in some way.

[SeRj-ThuramS]

Thank you :)

[SeRj-ThuramS]

I can't show you the project. It's private