Re: Procedure reminders on updating a lib package for a C++ ABI change
On Mon, Jul 18, 2005 at 09:00:13PM -0400, Nathanael Nerode wrote: ...but wait. If this is the case, isn't there a potential problem when a C++ program uses libGLU? Couldn't we end up with conflicting symbols from two different versions of libstdc++, one linked into libGLU and the other linked into the program which uses libGLU, and therefore possibly get unreliable or incorrect linkage at runtime? Or is libstdc++ using versioned symbols (in which case that can't happen)? Well, that's what the ABI change is about, isn't it? g++ _does_ emit a warning regarding two different libstdc++ libraries being uses and that being a potential cause of trouble. I haven't sit down and checked this symbol for symbol this time, but from the last time I did do it I remember that the symbols are either named different or mangled different or versioned different, e.g.: 0004c0d0 w DF .text 00f8 GLIBCPP_3.2 _ZNSi3getEv vs. 00062cb0 w DF .text 0103 GLIBCXX_3.4 _ZNSi3getEv -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure reminders on updating a lib package for a C++ ABI change
Marcello Magellon wrote: Keyword: implemented. All of GLU's interfaces are C, not C++, so transitioning libGLU is ill-advised at best. Hmm. I guess if libGLU *uses* C++ interfaces, but does not *export* any C++ interfaces, then it's effectively a program, not a library, for the purposes of the ABI change; it needs to be recompiled, but nothing depending upon it does. Is that what's going on here? Fun. That's a corner case none of us thought of. ...but wait. If this is the case, isn't there a potential problem when a C++ program uses libGLU? Couldn't we end up with conflicting symbols from two different versions of libstdc++, one linked into libGLU and the other linked into the program which uses libGLU, and therefore possibly get unreliable or incorrect linkage at runtime? Or is libstdc++ using versioned symbols (in which case that can't happen)? --Nathanael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure reminders on updating a lib package for a C++ ABI change
On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote: Also, for those who aren't aware, the new xorg packages now in unstable are also implicated in the C++ transition, because libGLU is implemented in C++. Keyword: implemented. All of GLU's interfaces are C, not C++, so transitioning libGLU is ill-advised at best. What I mean here is that no package should: a. Have an exclusive dependency on libglu1-xorg b. Have to wait for libglu1-xorg to enter etch c. Be trainsitioned because of libglu1-xorg libglu1-xorg reads: Replaces: libglu1c2, libglu1, libutahglx1, mesag3 ( 5.0.0-1), xlibmesa3 ( 4.2.1-5), xlibmesa3-glu, xlibmesa-glu Provides: libglu1c2 the provides is there in order to allow for other packages to provide libGLU, which is nice, thank you so much, but broken. Are you aware of a situation that needs this or are you doing this just in case? I have tried several GLU-using C++ and libraries compiled with g++ 3.3 with the binary provided by libglu1-xorg and they are working fine. I have also compiled programs against libglu1-xorg's libGLU and they run fine with other libGLUs compiled with gcc 3.3. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure reminders on updating a lib package for a C++ ABI change
On Sat, Jul 16, 2005 at 12:00:12PM -0600, Marcelo E. Magallon wrote: On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote: Also, for those who aren't aware, the new xorg packages now in unstable are also implicated in the C++ transition, because libGLU is implemented in C++. Keyword: implemented. All of GLU's interfaces are C, not C++, so transitioning libGLU is ill-advised at best. What I mean here is that no package should: a. Have an exclusive dependency on libglu1-xorg b. Have to wait for libglu1-xorg to enter etch c. Be trainsitioned because of libglu1-xorg libglu1-xorg reads: Replaces: libglu1c2, libglu1, libutahglx1, mesag3 ( 5.0.0-1), xlibmesa3 ( 4.2.1-5), xlibmesa3-glu, xlibmesa-glu Provides: libglu1c2 the provides is there in order to allow for other packages to provide libGLU, which is nice, thank you so much, but broken. Are you aware of a situation that needs this or are you doing this just in case? I have tried several GLU-using C++ and libraries compiled with g++ 3.3 with the binary provided by libglu1-xorg and they are working fine. I have also compiled programs against libglu1-xorg's libGLU and they run fine with other libGLUs compiled with gcc 3.3. Oh, ugh. I think the XSF was essentially following Ubuntu's lead here; no one realized, or thought to check, that the C++ bits weren't exported as part of the ABI. David, do you want me to put together a patch that updates the Provides/Conflicts of libglu1-xorg appropriately? (Might as well keep the name change now that it's been done, I think.) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Procedure reminders on updating a lib package for a C++ ABI change
On Sat, Jul 16, 2005 at 03:24:50PM -0700, Steve Langasek wrote: Oh, ugh. I think the XSF was essentially following Ubuntu's lead here; no one realized, or thought to check, that the C++ bits weren't exported as part of the ABI. Ah... that was my guess... David, do you want me to put together a patch that updates the Provides/Conflicts of libglu1-xorg appropriately? (Might as well keep the name change now that it's been done, I think.) The package name is not really a problem (libglu1-xorg is fine). Just the Provides needs to be fixed and set back to libglu1. If someone knows of a case where this breaks, please speak up now. Thanks, -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procedure reminders on updating a lib package for a C++ ABI change
On Sat, Jul 16, 2005 at 05:09:28PM -0600, Marcelo E. Magallon wrote: On Sat, Jul 16, 2005 at 03:24:50PM -0700, Steve Langasek wrote: Oh, ugh. I think the XSF was essentially following Ubuntu's lead here; no one realized, or thought to check, that the C++ bits weren't exported as part of the ABI. Ah... that was my guess... David, do you want me to put together a patch that updates the Provides/Conflicts of libglu1-xorg appropriately? (Might as well keep the name change now that it's been done, I think.) The package name is not really a problem (libglu1-xorg is fine). Just the Provides needs to be fixed and set back to libglu1. If someone knows of a case where this breaks, please speak up now. I'll fix this in the next upload. Thanks for calling it to my attention. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
