On Thu, 24 May 2001, Jonathan Sturges wrote: > I'm working on building and testing the Linux-PAM 0.75 modules under > Solaris 7/SPARC > 32-bit. I'm using gcc 2.95.2 and Sun's bundled "ld" for linking. > > [...] > > So the question I have is, I had to change the values of "LD_D" and "LD_L" > in the generated Make.Rules file in order to make the modules link properly > with Sun's "ld". > Since it appears these variables come from configure.in, I then updated > configure.in, and created a diff of the original configure.in and mine. I > figured this would cause the new values to be put in the Make.Rules during > the configuration process. However, I couldn't make "configure" complete > properly after patching configure.in. The diff I made from the modified > configure.in vs. original configure.in is simply: > > 272,273c272,273 > < LD_D="ld -G -z redlocsym" > < LD_L="ld -G -z redlocsym" > --- > > LD_D="gcc -shared -Xlinker -x" > > LD_L="$LD -x -shared" > > So the real question is, I want to suggest this change to the team. > However, since this minor change seems to screw up "configure" somehow, > what can I do? I guess I was hoping Andrew or someone else knows autoconf > and would know exactly how to make this right, if I were to submit a bug on > SourceForge. Making this minor change seems to make a big difference on > Solaris systems, and from looking at the context of the change in > configure.in, shouldn't affect Linux systems. About a year ago, I began submitting some Solaris portability patches to Linux-PAM. Many of these have been incorporated by Andrew, so it is now much better than it was then. But one of the outstanding issues is the need to get to grips seriously with use of autoconf, and with these linking issues. Understandably, Andrew is reluctant to be too "adventurous" in this area: the project was originally designed for Linux, it works there, so he is understandably cautious about changes. Alas, every OS does linking differently. Indeed, even within an OS, it will vary between compilers (eg. the native one and gcc). I suspect that what is really needed is to face this dilemma head-on (which will need a little courage!) and to introduce "libtool", which is specifically and purposefully designed for exactly these problems. (In the past "libtool" received a bad press because it wasn't perfect (what is?). But it is far better now, constantly improving, and we are, I hope, looking to the future...) Could I urge us to consider making such a transition on a branch in CVS? The portability payoff should be worth it. (As an example, the "linux-ha" project, led by Alan Robertson has just gone from no autoconf, automake or libtool to the full works in the last couple of months.) For the immediate problem: I had understood that generally the best way to do linking with "gcc" is to invoke it via "gcc" itself, letting it choose its preferred way (whether native "ld" or GNU "ld", as determined when gcc was itself installed). That is: the command we invoke should probably be of the form "gcc ..." rather than "ld ...". Hope that helps. -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham : : Phone: +44 191 374 2882 U.K. :
