I feel like this is a stupid question but I'm stuck.
Yesterday I nuked sid and installed ubuntu. I compiled libgc and installed it into /usr/local. I checked and the files are infact in /usr/local/lib. but configure is unable to find libgc. How can I tell configure where it is? I try running configure with "LDFLAGS=/usr/local/lib ./configure" and I get a message like "C compiler cannot create executables".
Aaron Spike
aaron@...749... wrote:
I feel like this is a stupid question but I'm stuck.
Yesterday I nuked sid and installed ubuntu. I compiled libgc and installed it into /usr/local. I checked and the files are infact in /usr/local/lib. but configure is unable to find libgc. How can I tell configure where it is? I try running configure with "LDFLAGS=/usr/local/lib ./configure" and I get a message like "C compiler cannot create executables".
More info: Ubuntu installs libgc 6.3 into /usr. so I'm assuming that configure finds this first and dies. I'm trying to build autopackages so the goal is for it to be linked in staticly. Any suggestions?
It was suggested that I just install libgc6.4 into /usr. That would be an easy way out (and what I remember doing last time). But I thought I'd hang on and see if there was any good lessons waiting for me.
Aaron Spike
Aaron, please see
http://sourceforge.net/mailarchive/message.php?msg_id=11914343
and followups.
I keep saying make install should ldconfig on Linux...
ralf
Ralf Stephan wrote:
http://sourceforge.net/mailarchive/message.php?msg_id=11914343 and followups. I keep saying make install should ldconfig on Linux...
Super, thanks very much. I'll give that a read and a try.
Aaron Spike
Quoting aaron@...749...:
It was suggested that I just install libgc6.4 into /usr. That would be an easy way out (and what I remember doing last time).
But
I thought I'd hang on and see if there was any good lessons
waiting
for me.
Personally, I'd not invite pain by bypassing the package system so lightly. ^_-
I'm on Gentoo now, and I just grabbed the libgc6.4 .debs from Debian and installed those. Works fine.
You will probably want to 'make uninstall' your copy from /usr/local first, though. Way back when I was starting with libgc I got myself in trouble neglecting to do that...
-mental
mental@...3... wrote:
Quoting aaron@...749...:
It was suggested that I just install libgc6.4 into /usr. That would be an easy way out (and what I remember doing last time).
But
I thought I'd hang on and see if there was any good lessons
waiting
for me.
Personally, I'd not invite pain by bypassing the package system so lightly. ^_-
I'm on Gentoo now, and I just grabbed the libgc6.4 .debs from Debian and installed those. Works fine.
You will probably want to 'make uninstall' your copy from /usr/local first, though. Way back when I was starting with libgc I got myself in trouble neglecting to do that...
Yeah I was afraid of installing to /usr on my nice new clean system. But I installed to /usr/local, edited /etc/ld.so.conf and ran ldconfig. That made things work (or seems to have made things work -- I'm still waiting for it to finish compiling). The reason I was building my own libgc is that Mike suggested I build libgc with apbuild for portability reasons. What are the pros/cons of what I have done?
Aaron Spike
ACSpike:
mental@...3... wrote:
Personally, I'd not invite pain by bypassing the package system so lightly. ^_-
mental has a point there. OTOH, this will then come up again the next time we need a library version where no deb exists.
Yeah I was afraid of installing to /usr on my nice new clean system. But I installed to /usr/local, edited /etc/ld.so.conf and ran ldconfig. That made things work (or seems to have made things work -- I'm still waiting for it to finish compiling). The reason I was building my own libgc is that Mike suggested I build libgc with apbuild for portability reasons. What are the pros/cons of what I have done?
Con: 1. Some packages don't support make uninstall. 2. You also might miss patches specific to your system applied by the deb providers (rarely needed but nevertheless).
Pro: You can fiddle with the source. One example would be building profiled versions of packages to look for performance bottlenecks. Etc. You have CONTROL, finally.
A workaround would be to build a package from the source specs (if existent) then install the package with dpkg. As this does not address Con 2, you would need the diffs provided by debian.org that they apply to the sources. But that's all and not too bad, given that most source packages have specs now.
ralf
participants (2)
-
unknown＠example.com -
Ralf Stephan