|
From: Jeremy F. <je...@go...> - 2002-12-15 00:23:35
|
I'm having trouble making RH8.0's buildrpm happy. There was a complaint
about an installed file not listed in the list of files (vg_regtest - I
just added it, but that doesn't seem like the right solution). Once I'd
fixed that, it generates an RPM, but it won't install it because it says
there's a dependency on glibc(GLIBC_PRIVATE). I presume it has
something to do with the __pthread_clock_(get|set)time stuff, but I
don't know what the fix is.
Any ideas?
Also, I think there should be valgrind and valgrind-devel packages, with
the latter containing the valgrind/*.h files.
J
|
|
From: Julian S. <js...@ac...> - 2002-12-15 01:13:39
|
> I'm having trouble making RH8.0's buildrpm happy. There was a complaint > about an installed file not listed in the list of files (vg_regtest - I > just added it, but that doesn't seem like the right solution). Once I'd > fixed that, it generates an RPM, but it won't install it because it says > there's a dependency on glibc(GLIBC_PRIVATE). I presume it has > something to do with the __pthread_clock_(get|set)time stuff, but I > don't know what the fix is. > > Any ideas? Blech. This is a swamp which I never really understood but managed to kludge a "fix" to a while back. My understanding, which could well be wrong, is as follows. __pthread_clock_gettime and __pthread_clock_settime are syms private to glibc (or is it libpthread), and correct programs shouldn't refer to them. So not exporting them from our libpthread.so is mostly OK. Problem is that some programs do refer to them -- IIRC /lib/librt.so on RH 7.3 sometimes needs them, and so I added the relevant kludges in coregrind/vg_libpthread.vs (linker script) and coregrind/vg_libpthread_unimp.c. Note that these people never actually needed to execute these functions [it seems]. They merely needed some definition of the syms in order that ld.so didn't barf at startup. So far so good. This _finally_ solved the problem for R H 7.3 folks and possible a few others. Meanwhile, Ulrich Drepper et al were (rightly) getting annoyed at people using unofficial interfaces in libc, and so have taken actions to make such private symbols invisible outside libc (or something like that, possibly including making RPM refuse to install libraries containing any such references, as you've seen). So I don't know; perhaps if you get rid of all mentions of those syms in the two abovementioned files, you might get a working arrangement. It would break other people tho. All this total crud is yet another reason why I'd like to rearrange V so that is is a standard C application which does all the ELF loading itself, as briefly discussed a couple of months ago. Then we wouldn't have to play these games. J |
|
From: Jeremy F. <je...@go...> - 2002-12-15 02:16:03
|
On Sat, 2002-12-14 at 17:21, Julian Seward wrote:
> So I don't know; perhaps if you get rid of all mentions of those syms
> in the two abovementioned files, you might get a working arrangement.
> It would break other people tho.
I wonder if there's another way of forcing/tweaking/suppressing package
dependencies from within the .spec file?
> All this total crud is yet another reason why I'd like to rearrange V so
> that is is a standard C application which does all the ELF loading
> itself, as briefly discussed a couple of months ago. Then we wouldn't have
> to play these games.
Hm, I don't think that's how it would pan out. I think the idea would
be that you'd "manually" build the initial address space for the target
application using the ELF file, but let the target app run a completely
standard ld.so running on the emulated CPU. However, to do threading,
you'd still need a special libpthread so V can catch all the thread
stuff and do something about it (unless you want to completely change
the thread model too).
J
|