bug#78072: Libtool incorrectly tries to use shared library when linking statically
Mike Krinkin <[email protected]> Mon, 28 Apr 2025 16:47:24 +0100
| Newsgroups | gmane.comp.gnu.libtool.bugs |
|---|---|
| Message-ID | <CACpa5=_zPRNgvOv1nVMNoEu-Bf+CmqczroH_QCR-Dj-JyWf6bg@mail.gmail.com> |
--0000000000005683400633d89a64 Content-Type: text/plain; charset="UTF-8" Hi Ileana, thank you for the response. I will try to test it out to confirm if your suggestions will fix the issue, it would take some time though. The problem in our case though is that colm for us is a dependency - it's not a project we own. So while I can apply changes you suggested to test if they work, that's not a solution we will be able to settle on. Is there any reason why --static flag that was provided to libtool is not enough indication to libtool to pick a static library over a shared one when both are available? If that behavior could be addressed somehow, IMO, it would be the best. Otherwise, I think, it would be just much easier for us to drop the la config alltogether rather than apply patches to a dependency. On Mon, 28 Apr 2025 at 16:42, Ileana Dumitrescu < [email protected]> wrote: > On 25/04/2025 21:53, Mike Krinkin wrote: > > Hi There, > > Hi Mike, > > Thank you for your bug report! > > > I hit a weird behaviour when build colm as part of building Envoy proxy. > > Cutting through layers of the stack on top of the libtool things here is > > what things boil down to: > > > > 1. we have a project using autogen/configure/libtool that was configured > > with `--enable-static` and `--disable-shared` > > 2. when I run make on the project one of the linking steps failed with > > the following error: > > > > ``` > > ld.lld: error: attempted static link of dynamic object > /usr/lib/libstdc++.so > > ``` > > > > There is a lot there, but two things that I believe are particularly > > relevant are: `--static` and `-lstdc++` flags. > > I believe that libtool next translated it into an actual command to link > > the binary and from the logs here is what I saw: > > > > It's pretty close to what we asked libtool to do with a few differences: > > it does not have -lstdc++ flag and instead passes /usr/lib/libstdc++.so > > along with other object files as input to the linker which obviously > > does not work. > > > > My understanding is that libtool looked at -lstdc++ flag, found a > > corresponding libstdc++.la file and "resolved" it into a shared library. > > > > What I'm baffled by in this case is why did libtool resolve it to a > > shared library instead of a static one, even though it's clearly a > > static build? > > Moreover, even if we wanted to link against the dynamic library, it > > should be done via -l flag, so what libtool looks very weird - we can't > > just link shared library as if it was a object file or a static library. > > Am I missing something or libtool is completely off the mark here and > > trying to do something weird? > > This issue is similar in some ways to a couple of bugs that have been > reported recently [1] [2]. Since you are using clang, '-static-libstc++' > is not available, so I think you would need to utilize other libtool > flags, either '-static-libtool-libs' or '-all-static'. Here [3] is the > section of the manual that explains them, and it would likely require > editing your Makefile.am to pass them to libtool. > > If updating your project configuration fixes this, I will close the bug. > Otherwise I will start reviewing the code for a way to fix this > behaviour. > > [1] https://savannah.gnu.org/support/?111184 > [2] https://savannah.gnu.org/support/?111202 > [3] https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html > > -- > Ileana Dumitrescu > > GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 > > --0000000000005683400633d89a64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Ileana,<div><br></div><div>thank you for the response. = I will try to test it out to confirm if your suggestions will fix the issue= , it would take some time though.</div><div><br></div><div>The problem in o= ur case though is that colm for us is a dependency - it's not a project= we own.</div><div>So while I can apply changes you suggested to test if th= ey work, that's not a solution we will be able to settle on.</div><div>= <br></div><div>Is there any reason why --static flag that was provided to l= ibtool is not enough indication to libtool to pick a static library over a = shared one when both are available?<br></div><div>If that behavior could be= addressed somehow, IMO, it would be the best. Otherwise, I think, it would= be just much easier for us to drop the la config alltogether rather than a= pply patches to a dependency.</div></div><br><div class=3D"gmail_quote gmai= l_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 28 Apr 202= 5 at 16:42, Ileana Dumitrescu <<a href=3D"mailto:ileanadumitrescu95@gmai= l.com">[email protected]</a>> wrote:<br></div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">On 25/04/2025 21:53, Mike Krinkin wrote:= <br> > Hi There,<br> <br> Hi Mike,<br> <br> Thank you for your bug report!<br> <br> > I hit a weird behaviour when build colm as part of building Envoy prox= y. <br> > Cutting through layers of the stack on top of the libtool things here = is <br> > what things boil down to:<br> > <br> > 1. we have a project using autogen/configure/libtool that was configur= ed <br> > with `--enable-static` and `--disable-shared`<br> > 2. when I run make on the project one of the linking steps failed with= <br> > the following error:<br> > <br> > ```<br> > ld.lld: error: attempted static link of dynamic object /usr/lib/libstd= c++.so<br> > ```<br> ><br> > There is a lot there, but two things that I believe are particularly <= br> > relevant are: `--static` and `-lstdc++` flags.<br> > I believe that libtool next translated it into an actual command to li= nk <br> > the binary and from the logs here is what I saw:<br> ><br> > It's pretty close to what we asked libtool to do with a few differ= ences: <br> > it does not have -lstdc++ flag and instead passes /usr/lib/libstdc++.s= o <br> > along with other object files as input to the linker which obviously <= br> > does not work.<br> > <br> > My understanding is that libtool looked at -lstdc++ flag, found a <br> > corresponding libstdc++.la file and "resolved" it into a sha= red library.<br> > <br> > What I'm baffled by in this case is why did libtool resolve it to = a <br> > shared library instead of a static one, even though it's clearly a= <br> > static build?<br> > Moreover, even if we wanted to link against the dynamic library, it <b= r> > should be done via -l flag, so what libtool looks very weird - we can&= #39;t <br> > just link shared library as if it was a object file or a static librar= y.<br> > Am I missing something or libtool is completely off the mark here and = <br> > trying to do something weird?<br> <br> This issue is similar in some ways to a couple of bugs that have been<br> reported recently [1] [2]. Since you are using clang, '-static-libstc++= '<br> is not available, so I think you would need to utilize other libtool<br> flags, either '-static-libtool-libs' or '-all-static'. Here= [3] is the<br> section of the manual that explains them, and it would likely require<br> editing your Makefile.am to pass them to libtool.<br> <br> If updating your project configuration fixes this, I will close the bug.<br= > Otherwise I will start reviewing the code for a way to fix this<br> behaviour.<br> <br> [1] <a href=3D"https://savannah.gnu.org/support/?111184" rel=3D"noreferrer"= target=3D"_blank">https://savannah.gnu.org/support/?111184</a><br> [2] <a href=3D"https://savannah.gnu.org/support/?111202" rel=3D"noreferrer"= target=3D"_blank">https://savannah.gnu.org/support/?111202</a><br> [3] <a href=3D"https://www.gnu.org/software/libtool/manual/html_node/Link-m= ode.html" rel=3D"noreferrer" target=3D"_blank">https://www.gnu.org/software= /libtool/manual/html_node/Link-mode.html</a><br> <br> -- <br> Ileana Dumitrescu<br> <br> GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354<br> <br> </blockquote></div> --0000000000005683400633d89a64--