As some have noticed, many platforms do not properly link C++ libraries when older, broken libtool versions are used during configure. This is actually also true on Linux (you'll see it link with gcc, not g++), but Linux seems to gloss over the problem.
The solution to this, which would greatly help the build process for our project, which is dependent on log4cpp, is to grab the latest libtool code from their cvs, and embed ltmain.sh and libtool.m4 inside your distribution. Then you point aclocal at your directory with the "-I ." option in your bootstrapping script, and it will stick the C++-friendly libtool macros in your configure process.
This is (or should be) mandatory for any C++ project using autoconf and libtool.
I don't really understand what you mean, the log4cpp dist tar ball does contain libtool (see config/ltmain.sh and aclocal.m4).
While it isn't the CVS version, but libtool 1.4.2, it appears to work OK. If someone needs a bleeding edge libtool version, like you apparently, running './autogen.sh' should do the trick.
Am I missing something here?
Bastiaan Bakker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It doesn't contain a libtool that works with C++. If you try and use gcc on Solaris, you'll see the end product shared library get linked with gcc, and not g++. This is wrong, and you won't have a usable library at the end.
I don't need a bleeding edge libtool, but any C++ project needs a version that supports C++, that's all.
If you think it works ok, you're on a platform on which gcc happens to link C++ by coincidence. This appears to be true on Linux. It's not other places.
Yes, I could run autogen, but then the main tarball distribution is still broken, so I'm just suggesting that fixing it makes sense. It's not hard.
If you're using C++, frankly, you're on the bleeding edge already, because Unix and C++ mix like oil and water where open source tools are concerned. Just the price of doing business right now.
We've not seen any problems with the cvs libtool, FWIW.
-- Scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, apparently you DO need a bleeding edge libtool, it doesn't get more bleeding edge than the CVS HEAD, does it ;-)
The projects for which I need log4cpp are all Linux based. So for me, libtool 1.4.2 suffices, and any update to it is only yet another possibility for regression. Not only for log4cpp itself but for all other parts of those project as well, since using multiple versions of the same tool in a project is a maintainance nightmare.
Of course I'm not against period updates to the tool chain. (You may have noticed that 0.3.4b has been built with autoconf 2.53 + automake 1.6.3 instead of 2.52/1.6.2 for instance), especially if it includes significant benefits to other people as well.
But think a second about your suggestion for 'cvs libtool'. That does not even specify a specific revision of the files. How am I to know that a libtool maintainer hasn't introduced a very nasty bug this morning? Also, if the libtool maintainers don't think the CVS trunk is ready for general consumption (and if they did, they would have built a release from it), I'm not inclined to use it.
Luckily for you the libtool folks released 1.4.3 last week, which contains your much wanted improvements I guess. Once it has become a bit more mainstream, I'm likely to adopt it.
So for now, include ./autogen.sh in your build script...
You may submit a 'feature request' as a reminder.
Good luck,
Bastiaan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, when I said I didn't need a new version, what I meant was that it's not *just* me. If you're ok with things as they are, it's your call. We'll just have to build a new distribution that works and provide that. I'll be happy to inform you of where it lives if you're willing to provide a link to it.
libtool < 1.5 does not support C++. I don't think 1.4.3 will help, but it's possible. I think the C++ support is in the 1.5/HEAD branch.
My philosophy is to use what works basically. If that means HEAD, that's all I can do. Anything else does not work on Solaris without manually linking the thing at the end with g++, which obviously is not a good solution.
-- Scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I'm trying to explain is that 'CVS HEAD' is a moving target, it's not even a revision, let alone a release. I trust the libtool folks to release 1.5 when it's ready. Since I haven't seen a 1.5 release, apparently it isn't ready yet.
Ergo if I upgrade to a new libtool now and our project builds at LifeLine break due to some obscure little bug, blame allocation goes to me and "but some dude on the internet said it reallly good" won't help.
If on some platforms 1.5 is a must for proper C++ support, I suggest that people working on those platforms help the libtool maintainers getting that release out the door.....
Cheers,
Bastiaan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if I thought I could realistically help them get 1.5 out the door, I would, but in the meantime, we'll build our own working log4cpp tarball and make do. I think 1.5 is not too far off, hopefully.
I certainly understand your concerns, though obviously were you using Solaris, you'd have already hit this problem and would have had no choice, basically.
As I said, we'll make our tarball accessible to others if they find it useful or needed, in the meantime. Thanks for your attention.
-- Scott
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As some have noticed, many platforms do not properly link C++ libraries when older, broken libtool versions are used during configure. This is actually also true on Linux (you'll see it link with gcc, not g++), but Linux seems to gloss over the problem.
The solution to this, which would greatly help the build process for our project, which is dependent on log4cpp, is to grab the latest libtool code from their cvs, and embed ltmain.sh and libtool.m4 inside your distribution. Then you point aclocal at your directory with the "-I ." option in your bootstrapping script, and it will stick the C++-friendly libtool macros in your configure process.
This is (or should be) mandatory for any C++ project using autoconf and libtool.
If I can help, let me know. You can take a look here for an example of what we're doing:
http://cvs.internet2.edu/cgi-bin/viewcvs.cgi/shibboleth/c/
Scott Cantor
cantor.2@osu.edu
Hi Scott,
I don't really understand what you mean, the log4cpp dist tar ball does contain libtool (see config/ltmain.sh and aclocal.m4).
While it isn't the CVS version, but libtool 1.4.2, it appears to work OK. If someone needs a bleeding edge libtool version, like you apparently, running './autogen.sh' should do the trick.
Am I missing something here?
Bastiaan Bakker
It doesn't contain a libtool that works with C++. If you try and use gcc on Solaris, you'll see the end product shared library get linked with gcc, and not g++. This is wrong, and you won't have a usable library at the end.
I don't need a bleeding edge libtool, but any C++ project needs a version that supports C++, that's all.
If you think it works ok, you're on a platform on which gcc happens to link C++ by coincidence. This appears to be true on Linux. It's not other places.
Yes, I could run autogen, but then the main tarball distribution is still broken, so I'm just suggesting that fixing it makes sense. It's not hard.
If you're using C++, frankly, you're on the bleeding edge already, because Unix and C++ mix like oil and water where open source tools are concerned. Just the price of doing business right now.
We've not seen any problems with the cvs libtool, FWIW.
-- Scott
Well, apparently you DO need a bleeding edge libtool, it doesn't get more bleeding edge than the CVS HEAD, does it ;-)
The projects for which I need log4cpp are all Linux based. So for me, libtool 1.4.2 suffices, and any update to it is only yet another possibility for regression. Not only for log4cpp itself but for all other parts of those project as well, since using multiple versions of the same tool in a project is a maintainance nightmare.
Of course I'm not against period updates to the tool chain. (You may have noticed that 0.3.4b has been built with autoconf 2.53 + automake 1.6.3 instead of 2.52/1.6.2 for instance), especially if it includes significant benefits to other people as well.
But think a second about your suggestion for 'cvs libtool'. That does not even specify a specific revision of the files. How am I to know that a libtool maintainer hasn't introduced a very nasty bug this morning? Also, if the libtool maintainers don't think the CVS trunk is ready for general consumption (and if they did, they would have built a release from it), I'm not inclined to use it.
Luckily for you the libtool folks released 1.4.3 last week, which contains your much wanted improvements I guess. Once it has become a bit more mainstream, I'm likely to adopt it.
So for now, include ./autogen.sh in your build script...
You may submit a 'feature request' as a reminder.
Good luck,
Bastiaan
Sorry, when I said I didn't need a new version, what I meant was that it's not *just* me. If you're ok with things as they are, it's your call. We'll just have to build a new distribution that works and provide that. I'll be happy to inform you of where it lives if you're willing to provide a link to it.
libtool < 1.5 does not support C++. I don't think 1.4.3 will help, but it's possible. I think the C++ support is in the 1.5/HEAD branch.
My philosophy is to use what works basically. If that means HEAD, that's all I can do. Anything else does not work on Solaris without manually linking the thing at the end with g++, which obviously is not a good solution.
-- Scott
What I'm trying to explain is that 'CVS HEAD' is a moving target, it's not even a revision, let alone a release. I trust the libtool folks to release 1.5 when it's ready. Since I haven't seen a 1.5 release, apparently it isn't ready yet.
Ergo if I upgrade to a new libtool now and our project builds at LifeLine break due to some obscure little bug, blame allocation goes to me and "but some dude on the internet said it reallly good" won't help.
If on some platforms 1.5 is a must for proper C++ support, I suggest that people working on those platforms help the libtool maintainers getting that release out the door.....
Cheers,
Bastiaan
Well, if I thought I could realistically help them get 1.5 out the door, I would, but in the meantime, we'll build our own working log4cpp tarball and make do. I think 1.5 is not too far off, hopefully.
I certainly understand your concerns, though obviously were you using Solaris, you'd have already hit this problem and would have had no choice, basically.
As I said, we'll make our tarball accessible to others if they find it useful or needed, in the meantime. Thanks for your attention.
-- Scott
OK, If you let me know where your tar ball lives, I'll add a pointer to it in the FAQ section.
Hopefully 1.5 will be out soon..
Bastiaan
We'll be maintaining a tarball here:
http://wayf.internet2.edu/shibboleth/
The one for 0.3.4b in the directory listing contains libtool macros from 1.4e, which is a recent build from CVS that links with the C++ compiler.
We have not tried it with CC on Solaris, but it does work with g++.
-- Scott