…40015)

### Rationale for this change

We need to link system libprotobuf.a too when we link libarrow.a, ORC is enabled and system Protobuf is used.

If we don't link system libprotobuf.a, some symbols are missing.

### What changes are included in this PR?

Add missing `${ARROW_PROTOBUF_LIBPROTOBUF}` to `ARROW_STATIC_INSTALL_INTERFACE_LIBS`.

### Are these changes tested?

Yes.

### Are there any user-facing changes?

Yes.
* Closes: #39919

Lead-authored-by: Sutou Kouhei <kou@clear-code.com>
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>

### Rationale for this change

See #40386, these changes are necessary for compatibility with Cython 3.0.9

### What changes are included in this PR?

This PR removes unnecessary `noexcept` clauses.

### Are these changes tested?

Covered by existing builds.

### Are there any user-facing changes?

No.

* GitHub Issue: #40386

Authored-by: Vyas Ramasubramani <vyasr@nvidia.com>
Signed-off-by: Felipe Oliveira Carvalho <felipekde@gmail.com>

…downloading packages (#39944)

### Rationale for this change

Old manylinux images seem to have issues with a GPG key in order to download packages.

### What changes are included in this PR?

Update the manylinux image used for the latest one.

### Are these changes tested?

Via archery jobs

### Are there any user-facing changes?

No
* Closes: #39943

Authored-by: Raúl Cumplido <raulcumplido@gmail.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>

…40486)

* GitHub Issue: #40485

Authored-by: AlenkaF <frim.alenka@gmail.com>
Signed-off-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>

… file (#40111)

### Rationale for this change

The `ParquetFileFragment` will cache the parquet metadata when loading it.  The `metadata()` method accesses this metadata (a shared_ptr) but does not grab the lock used to set that shared_ptr.  It's possible then that we are reading a shared_ptr at the same time some other thread is setting the shared_ptr which is technically (I think) undefined behavior.

### What changes are included in this PR?

Guard access to the metadata by grabbing the mutex first

### Are these changes tested?

Existing tests should regress this change

### Are there any user-facing changes?

No
* Closes: #40068

Authored-by: Weston Pace <weston.pace@gmail.com>
Signed-off-by: Antoine Pitrou <antoine@python.org>

We have had problems for a long time with a specific batch job that combines data from different sources. There is something in the data causing an Acero execution plan to hang or crash at random. The problem has been reproduced since Arrow 11.0.0, originally in Ruby, but it has also in Python. There is unfortunately no test case that reliably reproduces the issue in a release build.

However, in a debug build we can see that the batch job causes an overflow on the temp stack in arrow/cpp/src/arrow/compute/util.cc:38. Increasing the size of the stack created in the Acero QueryContext works around the issue, but a real fix should be investigated separately.

**This PR contains a "Critical Fix".**
* Closes: #39582

Lead-authored-by: Sten Larsson <sten@burtcorp.com>
Co-authored-by: Antoine Pitrou <antoine@python.org>
Signed-off-by: Antoine Pitrou <antoine@python.org>

…40259)

### Rationale for this change

On the CRAN build machines the GNU libtool is on the path in front of the macOS libtool. Though these are named the same thing, they are actually very different and don't actually appear to be substitutes

I checked on a non-developer's machine to see if `/usr/bin/libtool` exists, and it did. So I believe we _should_ be ok with this even if xcode / command line tools haven't been installed.

One note: it's possible that we could get the GNU libtool in link mode to work with the right incantation (something like `libtool --mode=link --tag=CXX ${cmake_compiler} -o ...` but when I tried this I kept getting symbol not found errors. Ultimately, I think any mac that we are on will have the apple-provided libtool, so decided to go the route of finding it. 

### What changes are included in this PR?

When we detect we are on a GNU libtool, we look to `/usr/bin/libtool` instead.

### Are these changes tested?

Yes. See a broken config failing at #40259 (comment) and then the next one passes

### Are there any user-facing changes?

We will remain on CRAN

**This PR contains a "Critical Fix".**
* GitHub Issue: #40248

Lead-authored-by: Jonathan Keane <jkeane@gmail.com>
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
Signed-off-by: Jonathan Keane <jkeane@gmail.com>

…lation with nvcc (#40253)

### Rationale for this change

The current code uses an incomplete type in a SFINAE construct.

Closes #40252 

### What changes are included in this PR?

This PR changes the way that the type is specified to avoid any UB.

### Are these changes tested?

I tested locally that code that originally failed to compile with nvcc now compiles successfully. The same code also compiles under clang and gcc. This is a minimal reproducer:
```
#include <arrow/api.h>
#include <vector>

int main() {
  arrow::util::span<int> x{std::vector<int>{1, 2, 3}};
}
```

I did not include it here because it is a compile-time rather than runtime issue, and because at present it only manifests on nvcc.

### Are there any user-facing changes?

No.

* GitHub Issue: #40252

Authored-by: Vyas Ramasubramani <vyasr@nvidia.com>
Signed-off-by: Antoine Pitrou <antoine@python.org>