fix build for gcc 14

[AiraYumi]

Fix build error for gcc 14

It has not yet been completely fixed.
There may be some false positives.

[nat-goodspeed]

I'll run the builds and we'll see.

[nat-goodspeed]

This change makes me raise my eyebrows. I can't think of a reason why a lambda with a literally empty body would need any bindings.

[Ansariel]

It makes no sense in all of the changes in this PR.

[nat-goodspeed]

In fact, clang actively dislikes it:

/Users/runner/work/viewer/viewer/indra/newview/llinventorygallerymenu.cpp:329:85: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
  329 |             boost::function<void(std::string& slurl)> copy_slurl_to_clipboard_cb = [this](const std::string& slurl)
      |                                                                                     ^~~~
1 error generated.

[AiraYumi]

gcc14 marks all changes as errors. Maybe all the errors it detects are false positives.
I was not able to build the viewer properly using gcc14 and gcc13 in my environment.

[AiraYumi]

gcc 14 or 13 error list

• dangling−pointer
• maybe uninitialized
• uninitialized

[nat-goodspeed]

Maybe we must tell gcc users to skip versions 13 and 14? We certainly can't accept changes that break clang builds.

[AiraYumi]

Skipping gcc 13 and 14 may be appropriate.
The default for ubuntu24.04 is gcc13. The default for gentoo (ubuntu24.10) is gcc14.
Documentation for users who are using it may be needed.

[AiraYumi]

Since there is no prospect of being able to build with gcc13 and 14, I am thinking of canceling this PR. What do you think?

[nat-goodspeed]

I have to agree. I can't think of a cleaner way to pacify gcc 13 and 14 while preserving the ability to build with clang and others than something like:

#if <gcc13> or <gcc14>  // whatever tests we use for that
#define GCC13THIS this
#else  // everybody else
#define GCC13THIS
#endif // not gcc13 or gcc14
// ...
auto callback = [GCC13THIS](...){ ... };

which is still pretty ugly.