Re: Frontpage and Debian (SOLVED!)
Adam, trust me, I went through this three months ago, I got involved in some significant discussion on rtr's forum, and the best possible solution, the one that rtr itself recommends, is the one I described above. Put the special libraries in a special place, and let apache know about it using SetEnv. This is the only thing that will keep all of your programs happy, which means it's the only way that you're not going to end up pulling your hair out down the road. This is what I have done and apart from a spelling mistake in the httpd.conf file (DOH!) everything seems to be working great. Thanks, Adam. - Earthlight Communications Limited P.O. Box 5301 Adam Shand (fax) +64 3 477 5463 Dunedin, New Zealand Systems Manager(voice) +64 3 479 0303 http://www.earthlight.co.nz/larry/
Re: Frontpage and Debian (SOLVED!)
One way to deal with this would be to downgrade to the old library, then copy the installed libraries, by hand, into /usr/local/lib. You can then upgrade back to the current libraries and everything should work without the need for the LD_PRELOAD. I'm very new to this but couldn't you end up with nasty things happening if you did this and upgraded to the new version of libg++? Cause if you compile things and it uses the new header files but the /usr/local/lib is first in the search path...? Thanks, Adam. - Earthlight Communications Limited P.O. Box 5301 Adam Shand (fax) +64 3 477 5463 Dunedin, New Zealand Systems Manager(voice) +64 3 479 0303 http://www.earthlight.co.nz/larry/
Re: Frontpage and Debian (SOLVED!)
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale On Tue, 8 Apr 1997, Steffen R. Mueller wrote: Dale One way to deal with this would be to downgrade to the old Dale library, then copy the installed libraries, by hand, into Dale /usr/local/lib. You can then upgrade back to the current Dale libraries and everything should work without the need for the Dale LD_PRELOAD. What prevents from using dpkg -x /tmp/old-lib and then move the old libraries to /usr/local? This way we don't downgrade and risk anything breaking. Maybe I'm missing something. manoj -- Pink Panther Kato, what is going on in that little yellow brain of yours? Chief Inspector Clouseau, in reference to a priceless white\ Steinway piano. Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/
Re: Frontpage and Debian (SOLVED!)
On Wed, 9 Apr 1997, Adam Shand wrote: One way to deal with this would be to downgrade to the old library, then copy the installed libraries, by hand, into /usr/local/lib. You can then upgrade back to the current libraries and everything should work without the need for the LD_PRELOAD. I'm very new to this but couldn't you end up with nasty things happening if you did this and upgraded to the new version of libg++? Cause if you compile things and it uses the new header files but the /usr/local/lib is first in the search path...? You are confusing ld.so with gcc. The compiler/linker doesn't search /usr/local, you would need to direct it to look there. What you need to put into /usr/local/lib is the shared libraries used by ld.so during program loading. This path is on the list of paths checked by ld.so and will result in the correct library being available to the program that needs it. Luck, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: Frontpage and Debian (SOLVED!)
Dale Scheetz [EMAIL PROTECTED] writes: You are confusing ld.so with gcc. The compiler/linker doesn't search /usr/local, you would need to direct it to look there. What you need to put into /usr/local/lib is the shared libraries used by ld.so during program loading. This path is on the list of paths checked by ld.so and will result in the correct library being available to the program that needs it. Dale, I'm afraid that you are the one who is confused. That entire paragraph is incorrect. First, ld _does_ search /usr/local by default. This is easy to test, but it's also easy to check other ways: $ strings /usr/bin/ld | egrep /usr/local/lib SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/elf_i386/lib); SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/elf_i386/lib); SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/elf_i386/lib); Second, your analysis of ld.so's behavior is wrong. The fact is, the two versions of libg++ have the same soname. Thus ld.so cannot, for all intents and purposes, distinguish between them. So only one of these will be visible through ld.so, and it's going to be the same one for all programs, and it's inevitably going to be the wrong version for one of those programs If you doubt this, please experiment with the procedure you suggest. Try putting an alternate version of libg++ in /usr/local/lib, run ldconfig, then run ldconfig -p. You will find only one listing for libg++---I don't think it's documented _which_ one will show up, but it'll only be one. Adam, trust me, I went through this three months ago, I got involved in some significant discussion on rtr's forum, and the best possible solution, the one that rtr itself recommends, is the one I described above. Put the special libraries in a special place, and let apache know about it using SetEnv. This is the only thing that will keep all of your programs happy, which means it's the only way that you're not going to end up pulling your hair out down the road. Mike.
Re: Frontpage and Debian (SOLVED!)
-BEGIN PGP SIGNED MESSAGE- On 09-Apr-97 Michael Alan Dorman wrote: Dale Scheetz [EMAIL PROTECTED] writes: You are confusing ld.so with gcc. The compiler/linker doesn't search /usr/local, you would need to direct it to look there. What you need to put into /usr/local/lib is the shared libraries used by ld.so during program loading. This path is on the list of paths checked by ld.so and will result in the correct library being available to the program that needs it. Mike is right. The only paths searched BY DEFAULT by ld.so are /lib and /usr/lib. The others are added in the /etc/ld.so.conf file. Dale, I'm afraid that you are the one who is confused. That entire paragraph is incorrect. First, ld _does_ search /usr/local by default. This is easy to test, but it's also easy to check other ways: $ strings /usr/bin/ld | egrep /usr/local/lib SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/elf_i386/lib); SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/elf_i386/lib); SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/elf_i386/lib); Second, your analysis of ld.so's behavior is wrong. The fact is, the two versions of libg++ have the same soname. Thus ld.so cannot, for all intents and purposes, distinguish between them. So only one of these will be visible through ld.so, and it's going to be the same one for all programs, and it's inevitably going to be the wrong version for one of those programs If you doubt this, please experiment with the procedure you suggest. Try putting an alternate version of libg++ in /usr/local/lib, run ldconfig, then run ldconfig -p. You will find only one listing for libg++---I don't think it's documented _which_ one will show up, but it'll only be one. Adam, trust me, I went through this three months ago, I got involved in some significant discussion on rtr's forum, and the best possible solution, the one that rtr itself recommends, is the one I described above. Put the special libraries in a special place, and let apache know about it using SetEnv. This is the only thing that will keep all of your programs happy, which means it's the only way that you're not going to end up pulling your hair out down the road. Mike. Have a good one. - -- Rick Jones E-Mail: Rick [EMAIL PROTECTED] Date: 09-Apr-97 Time: 09:48:52 - -- -BEGIN PGP SIGNATURE- Version: 2.6.2 iQCVAwUBM0ueUQi+Ph+i3TgpAQFTsAQAm5XGuUCiRih2KEFz7uZ1GkN5YJ6un/rM lq8c88NQwysdg/bHTGQEvqp8dSFV1YauvR6U5wk39C4ckAF8gL287GoGwrc0ICZi yvmN6tNj+nD8ByUVA2Az5HTQ/nafGt3o+ody7Y0BlSPOSuuogC7NOMDO074z9Mtk t267T0gGE6c= =UlPW -END PGP SIGNATURE-
Re: Frontpage and Debian (SOLVED!)
On 8 Apr 1997, Manoj Srivastava wrote: Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale On Tue, 8 Apr 1997, Steffen R. Mueller wrote: Dale One way to deal with this would be to downgrade to the old Dale library, then copy the installed libraries, by hand, into Dale /usr/local/lib. You can then upgrade back to the current Dale libraries and everything should work without the need for the Dale LD_PRELOAD. What prevents from using dpkg -x /tmp/old-lib and then move the old libraries to /usr/local? This way we don't downgrade and risk anything breaking. I had not thought of that. This would mean that you would not, even for a few minutes, be without the more recent libraries. Maybe I'm missing something. I don't think so... Waiting is, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: Frontpage and Debian (SOLVED!)
On 9 Apr 1997, Michael Alan Dorman wrote: Dale Scheetz [EMAIL PROTECTED] writes: You are confusing ld.so with gcc. The compiler/linker doesn't search /usr/local, you would need to direct it to look there. What you need to put into /usr/local/lib is the shared libraries used by ld.so during program loading. This path is on the list of paths checked by ld.so and will result in the correct library being available to the program that needs it. Dale, I'm afraid that you are the one who is confused. That entire paragraph is incorrect. This doesn't surprise me very much ;-) I have always been secure in the knowledge that, if I say something stupid, there is always someone brighter than myself to point it out. Thanks for improving my knowledge. Your solution is a good one. If the so numbers were different, you would be able to add the special path to its config and not need to specify the path on invocation, right? I seem to have missed several crucial pieces of data. Thanks, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: Frontpage and Debian (SOLVED!)
Hi. Sorry for the follow-up post so soon after. I managed to find a copy of the old libg++ 2.7.1 that I needed on the September 1996 Infomagic CD. For anyone interested if you want the FP97 extensions to work with Debian linux all you need to do is is *downgrade* libg++ to version 2.7.1 and it all becomes easy. If anyone needs help I'll be happy to provide what help I can. Adam.
Re: Frontpage and Debian (SOLVED!)
Thus spake Adam Shand ([EMAIL PROTECTED]): Hi. Hi Adam, Sorry for the follow-up post so soon after. I managed to find a copy of the old libg++ 2.7.1 that I needed on the September 1996 Infomagic CD. For anyone interested if you want the FP97 extensions to work with Debian linux all you need to do is is *downgrade* libg++ to version 2.7.1 and it all becomes easy. If anyone needs help I'll be happy to provide what help I can. Was it really necessary to downgrade the complete system ? I wonder if it is possible to use the LD_PRELOAD feature like the one used by the netscape installer package. Greetings, Steffen -- - NTG Netzwerk und Telematic GmbH, Sitz Chemnitz. Kreisgericht Chemnitz/Stadt HRB 4217 Geschaeftsfuehrer: Michael Rotert - Steffen R. Mueller __ ___ _ _ email: [EMAIL PROTECTED] NTG Netzwerk und Telematic GmbH\ \/ / (_)_ __ | | __ fax : +49 721 9652 210 Geschaeftsbereich Xlink \ /| | | '_ \| |/ / phone: +49 721 9652 211 Vincenz-Priessnitz-Str. 3 / \| | | | | | RIPE : SM25-RIPE D-76131 Karlsruhe, Germany /_/\_\_|_|_| |_|_|\_\ WWW.Xlink.net/~steffen INTERNET. MIT SICHERHEIT
Re: Frontpage and Debian (SOLVED!)
For anyone interested if you want the FP97 extensions to work with Debian linux all you need to do is is *downgrade* libg++ to version 2.7.1 and it all becomes easy. If anyone needs help I'll be happy to provide what help I can. Was it really necessary to downgrade the complete system ? I wonder if it is possible to use the LD_PRELOAD feature like the one used by the netscape installer package. Maybe... if anyone knows anything about this (I don't) and would be willing to show me how or point me at something that will teach me how I'll give it a go... otherwise it'll just have to stay as is until M$ gets around to recompiling against the later libs. Adam.
Re: Frontpage and Debian (SOLVED!)
On Tue, 8 Apr 1997, Steffen R. Mueller wrote: Thus spake Adam Shand ([EMAIL PROTECTED]): Hi. Hi Adam, Sorry for the follow-up post so soon after. I managed to find a copy of the old libg++ 2.7.1 that I needed on the September 1996 Infomagic CD. For anyone interested if you want the FP97 extensions to work with Debian linux all you need to do is is *downgrade* libg++ to version 2.7.1 and it all becomes easy. If anyone needs help I'll be happy to provide what help I can. Was it really necessary to downgrade the complete system ? I wonder if it is possible to use the LD_PRELOAD feature like the one used by the netscape installer package. One way to deal with this would be to downgrade to the old library, then copy the installed libraries, by hand, into /usr/local/lib. You can then upgrade back to the current libraries and everything should work without the need for the LD_PRELOAD. Luck, Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
