| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
Failed to run locate.updatedb after upgrading to libcrypt-1.2.6 (??)
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 Failed to run locate.updatedb after upgrading to libcry... - Jul. 4, '06, 10:59:58 PM
|
|
|
silentstep
Posts: 6
Joined: Jun. 15, '06,
Status: offline
|
I got the following message when executing locate.updatedb
bash-3.00$ /usr/local/libexec/locate.updatedb
mktemp: error in loading shared libraries
: undefined symbol: __alloca
Reinstalling dependencies does not help. Anyone experiences this problem?
|
|
|
|
|
RE: Failed to run locate.updatedb after upgrading to li... - Jul. 5, '06, 12:26:45 AM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Well that's wierd.
I can replicate the problem. It's wierd because libcrypt isn't
responsible for the _alloca() API. If I relink mktemp (the utility
in question) then _alloca() gets changed from undefined to local.
For some reason _alloca() got shoved into version 1.2.5 of libcrypt
for the shared library version. It shouldn't have been; the static version
is fine (doesn't have it)...
Ah-ha I see the situation of it now.
I had built the objects before with gcc and then made
these objects into the shared library with gcc. This build had the
objects built with c89 and then made as a shared library with gcc.
The c89 code has no want of _alloca() -- that's purely a gcc object result.
I'll issue 1.2.6.1 of libcrypt in a short bit to fix this.
This could have resulted in few DEP's going off (on 3.5) with shared libararies
still being used but clearly has other side effects. I'll have to experiment with
this thing. There may be a redeeming result from it yet.
< Message edited by Rodney -- Jul. 5, '06, 12:38:06 AM >
|
|
|
|
|
RE: Failed to run locate.updatedb after upgrading to li... - Jul. 5, '06, 1:02:38 AM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
All-right, here's some sweet information.
First VC++ 2003 and VC++ 2005 can both be downloaded and installed for free.
VC++ is what c89/cc use. So this makes the "cost barrier" a non-issue.
If all of the objects of an application are compiled (note: just compiled) with
c89 or cc then the stack is never used for temporary memory; that
was what the alloca() API call is doing. Further, no executable code is going to
be placed on the stack (that's key for DEP). Then gcc can be used to either
form the objects into a .so/DSO or be used to link the app to shared libraries;
things c89/cc can't do. The end result is apps using shared libs and DSO's
that won't trigger DEP on 5.2, etc. even though built on 3.5.
Putting this into practice is a lot more difficult given the millions of lines of
code and hundreds of packages. But it is a workaround that might help someone with
a more focused agenda.
|
|
|
|
|
RE: Failed to run locate.updatedb after upgrading to li... - Jul. 5, '06, 2:30:13 AM
|
|
|
Rodney
Posts: 3728
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Libcrypt has been patched back to have alloca() in it.
If you do "pkg_update -L libcrypt" then mktemp will start to work again.
|
|
|
|
|
RE: Failed to run locate.updatedb after upgrading to li... - Jul. 5, '06, 3:50:26 AM
|
|
|
silentstep
Posts: 6
Joined: Jun. 15, '06,
Status: offline
|
Yes, the new package solves the problem now. Thanks Rodney.
< Message edited by silentstep -- Jul. 5, '06, 3:51:55 AM >
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
