At 20:12 Uhr -0500 24.01.2002, David R. Morrison wrote: >Max, con you explain this little item in your patchfile for the new >libxml2 from today? You've patched Makefile.in with > >-LDFLAGS = @LDFLAGS@ >+LDFLAGS = -L./.libs @LDFLAGS@ > >and I'm curious about what this does and why it's necessary. (And if >the same effect could be achieved with SetLDFLAGS .)
To quote the .info file: DescPort: << The Makefile is too stupid to link the executables against the right copy of the library, so we help by setting LDFLAGS. << You see, libxml2 uses libtool to link libraries. Libtool in turn links the libraries and puts the results inside a subfolder called .libs. So it does that, and as the package continues to build, other parts of it need to link against that shared library. But obviously the lib is not yet installed, hence we have to tell the linker where it can find it - namely using the -L./.libs option. Indeed, libtool does all that automatically for us - and it does so for libxml2, too. However, due to some strange problem in libxml2, libtool will at one point mix up the order of the -L statments. The link command then will contain -L/sw/lib before -L./.libs. This would not make a difference was it not for the fact that I (and most other fink users I guess) already have a copy of libxml installed. The linker always chooses the first instance of a lib that it can find, hence the linker will try to link against the installed version - which is wrong, we don't want to link against that one. Problems like this often go unnoticed, and may or may not cause problems (if they do, it's a nightmare to track down :/). But in this case, "luckily" the wrong linking order causes a link error, as the older libxml2 lib version doesn't define some functions provided by the new one. So, to fix it, I am forcefully adding a -L./.libs *in front* of all other LDFLAGS. Yes, this could also be achieved via a SetLDFLAGS (and some other packages use this trick, too, I think, or at least used to). But then it will break building one of the examples. Reason: at that point the examples/.libs dir is not yet created. Granted, I could create the missing directoy in my CompileScript. Instead, I am simply modifying the Makefile for the directory which is affected, thus making the changed LDFLAGS local to that dir. This means the examples/tests subdirs will have executables linked against the wrong version of the shared lib, but since they get discarded anyway, that doesn't matter so much. Strictly spoken, this is a hack that fixes the symptoms, but doesn't solve the actual problem. I did not yet have the time (nor the nerves I admit :) to dig deeply into this and find out what exactly is causing it in the first place (the wrong order of the -L statments is probably induced by some .lo file, but i haven't yet tracked this down precisely), >I'm asking because I was getting strange errors when I tried to port >libxml2-2.4.x a while back, and you obviously succeeded. And although >I can't remember exactly what those errors were, I know I've seen similar >ones in other contexts, so it would be useful to know about this. I hope the above clarifies it. If not, please ask. And indeed, this problem did, does and will crop up in other packages. Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
