Figure out strategy for dealing with `--disable-shared --enable-static`

[ndarilek]

I'm using this crate to vendor and build dependencies for my spatialite-sys crate. Unfortunately, the hard-coded --disable-shared --enable-static options cause failures in Spatialite's configure script. I guess it searches for some of its dependent functions and expects to find them in a shared library.

I don't know what the best solution is, but for now I removed --disable-shared and everything now works. I assume this means that static libraries still build where supported, but that shared libraries are available for configure checks that need them. Seems like it might be the best of both worlds. I'm happy to contribute a PR to that effect if you think it's the best way forward.

[lu-zero]

the resulting code could be broken, is it possible to fix upstream? (the static library probably is checked without its link line or, even worse, w/out using pkg-config)

[ndarilek]

Ugh, I'm not nearly smart enough to push a fix upstream. I'd rather determine that my build *is* broken and work to fix the breakage, rather than speculate that it might be and try to continue using these options. And, FWIW, my hacked-together shell script hasn't needed static linking to build working libraries before, so I'm not even sure that I'm doing anything wrong here. So let's brainstorm ways to make these features optional. Maybe `.enable_shared()` and `.enable_static()` methods, with neither enabled by default, and a 0.2 release incorporating those changes?

[ndarilek]

Or actually, why wouldn't just removing --disable-shared from the defaults work? Does this not still imply the presence of --enable-static, so if something needs a static build, it would still happen and be present in the prefix?

Autotools is a bit of a dark art to me, so I'm not sure what the best way forward is. Just trying to find something minimally invasive.

[lu-zero]

We could change the defaults and let the users pick their poison.

Are you willing to prepare two options for this purpose?

[ndarilek]

I can do that. So you'd rather not just remove --disable-shared? Why, just out of curiosity? Seems like it'd be the best of both worlds, but again, I don't understand autotools beyond the basics, so maybe there's some pitfall I'm missing.

I just checked my build outputs, and there are .a files for all of my dependencies. So everything is definitely getting built statically. I think what's happening is that the function being checked for in the failing autoconf test is a C++ function wrapped by a C library, and the linker is failing to pass the test because it isn't statically linking the C++ STL. In the config.log I see a bunch of missing references to what appear to be standard C++ functions, so it looks like the test is using the shared library by default, and the only purpose of the test is making sure you've got a new enough library that includes the function in question. The library presence test already passes fine. So the failure isn't that the missing function doesn't exist in the target library, but rather that the autoconf test doesn't work if only a static build is made. So I guess removing --disable-shared by default would create libraries that may not build if I'm not statically linking in the C++ STL, but IMO the way to make that error go away is to use the library on multiple targets and fill out the CFLAGS for each, if necessary, not to fail the build and not even let me figure out what extra flags I need.

Anyhow, I'm happy to add both options, just wanted to check that the simpler solution wouldn't be workable.

[lu-zero]

I'm about to take a plane so sorry for the format Ideally you always want to link statically beside corner cases, since you cannot install libraries through cargo.

…

On Fri, Feb 8, 2019, 14:29 Nolan Darilek ***@***.*** wrote: I can do that. So you'd rather not just remove --disable-shared? Why, just out of curiosity? Seems like it'd be the best of both worlds, but again, I don't understand autotools beyond the basics, so maybe there's some pitfall I'm missing. I just checked my build outputs, and there are .a files for all of my dependencies. So everything is definitely getting built statically. I think what's happening is that the function being checked for in the failing autoconf test is a C++ function wrapped by a C library, and the linker is failing to pass the test because it isn't statically linking the C++ STL. In the config.log I see a bunch of missing references to what appear to be standard C++ functions, so it looks like the test is using the shared library by default, and the only purpose of the test is making sure you've got a new enough library that includes the function in question. The library presence test already passes fine. So the failure isn't that the missing function doesn't exist in the target library, but rather that the autoconf test doesn't work if only a static build is made. So I guess removing --disable-shared by default would create libraries that may not build if I'm not statically linking in the C++ STL, but IMO the way to make that error go away is to use the library on multiple targets and fill out the CFLAGS for each, if necessary, not to fail the build and not even *let* me figure out what extra flags I need. Anyhow, I'm happy to add both options, just wanted to check that the simpler solution wouldn't be workable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOlpPqz2uD2zfDcz6yxECIfsLqQMeLRks5vLXuogaJpZM4avdKy> .

[ndarilek]

No worries. I'd like to release spatialite-sys 0.2 with an autotools-driven build.rs, but in the meantime I'll try just removing --disable-shared and make my crates use my autotools fork and spatialite-sys from git. If it works, then maybe we can just remove --disable-shared since we're still getting static builds with --enable-static. I'll report back with my results.

[lu-zero]

I do not have strong opinions, I'd keep the default behavior what I consider the most common situation:

• build some library static
• embed it (or portions of it) in some rust code

But I'm fine in letting people use the crate for other purposes (e.g. building plugins).