on 4/28/09 3:30 PM, Joerg Bruehe at joerg.bru...@sun.com uttered the
following:
>>>> cxx: Error: ../../sql/log.h, line 140: identifier "pthread_mutex_destroy"
>>>> is
>>>> undefined
>>>> ~st_log_info() { pthread_mutex_destroy(&lock);}
>>>> -------------------^
>>>> cxx: Error: ../../sql/log.h, line 401: identifier "pthread_mutex_unlock" is
>>>> undefined
>>>> inline void unlock_index() { pthread_mutex_unlock(&LOCK_index);}
>>>> -------------------------------^
>>>> cxx: Info: 2 errors detected in the compilation of "transparent_file.cc".
>
> This means the header files accessed don't include the appropriate
> function definitions, so it fails to compile.
/usr/include/pthread.h is used and does define all this and not with some
flag specifically for some of the identifiers...
> I haven't checked the requirements - it may well be that the Intel CPUs
> don't care about "unaligned access" whereas the Digital's Alpha does.
That's probably the case.
> This will happen if the compiler doesn't care about the necessary
> alignment of variables. It surprises me that this should happen with
> gcc, but I haven't accessed Tru64 (or any other system on Alpha, like
> Linux/Alpha) for quite some time.
I'm trying to use the native compilers hoping they will prevent that.
> I'm speculating a bit:
> - The message says "undefined", so it claims the header file(s) used
> don't include the function name.
But pthread.h does, that's what I can't understand.
> - You say they are defined in "/usr/include/pthread.h".
Yes.
> - I propose you check the file contents to make sure this definition
> does not depend on some cpp symbol which might be unset.
Already have, I had made sure when I found that out.
Just for kicks, I tried something to double check on this, I changed the
pthread_mutex_unlock in log.h into pthread_mutex_lock to see what would
happen, and the error on that line went away, so pthread_mutex_lock is
defined while pthread_mutex_unlock isn't.
Here are a few tidbits from my pthread.h that define those particular
identifiers:
#ifdef _PTHREAD_USE_MANGLED_NAMES_
# ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix "__"
# else
# define pthread_mutex_destroy __pthread_mutex_destroy
# endif
#endif
extern int pthread_mutex_destroy (pthread_mutex_t*);
#ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix ""
#endif
#ifdef _PTHREAD_USE_MANGLED_NAMES_
# ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix "__"
# else
# define pthread_mutex_lock __pthread_mutex_lock
# endif
#endif
extern int pthread_mutex_lock (pthread_mutex_t*);
#ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix ""
#endif
#ifdef _PTHREAD_USE_MANGLED_NAMES_
# ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix "__"
# else
# define pthread_mutex_unlock __pthread_mutex_unlock
# endif
#endif
extern int pthread_mutex_unlock (pthread_mutex_t*);
#ifdef _PTHREAD_USE_PTDNAM_
# pragma extern_prefix ""
#endif
I'm wondering if _PTHREAD_USE_MANGLED_NAMES_ is used or not, but in any
case, each identifier is handled the same and it wouldn't behave differently
for a specific identifier.
Would you like me to send you the header file?
> If you are sure that's not the problem, I propose:
>
> # Get the time of last read access of that header file:
> ls -lu /usr/include/pthread.h
>
> # Try to translate the problematic module.
> # Assuming "make" finds all preceding files are built,
> # this should try the problematic module only:
> make 2>&1 | tee /some/where/to.log
>
> # Check whether the header file was read:
> ls -lu /usr/include/pthread.h
>
> # Check the log file, whether "transparent_file.cc" was
> # really the only one handled.
I'm redoing an other build from scratch and saving the whole configure and
make process in a log, along with the ls -u on the header each time.
If I sent you all that, would that help?
> The plain "make" should get all settings etc from the configured
> Makefile, so it shouldn't need any options.
I'm using a shell script to handle the whole thing in one shot, distclean,
configure, make and all... I use environment variables and I set higher
ulimits as well.
> If you still find the header file was really accessed, your next step
> would be to use "-E" as a compile option, so that the sources are
> handled by cpp and you can analyze the expanded text.
That's going outside of my abilities, unless you told me what to look for in
the output, I probably couldn't really figure it out, I'm not a C
programmer. But after this current build if there isn't enough hints to
figure this out, I can try this again, logging it all and see what we can
dig out..
>>> I assume that you cc/ld need some special options to find it.
>>
>> The options are there, it's -pthread and if that wasn't there I would get a
>> lot more errors because pthread.h wouldn't be used at all. Using -pthread
>> with cc makes ld use -lpthread so it's working fine, except for those 2
>> identifiers out of the bunch.
>
> "-lpthread" is an option for the link phase, to use that library.
> Your error message occurs earlier, in the compile phase for the
> individual module(s).
Of course, but using the -pthread earlier causes the use of the -lpthread
and others to be used at link time.
> TTBOMK, MySQL AB never had their own Tru64 box, and definitely there is
> none available now. When MySQL AB previously offered binaries for Tru64,
> they were built on an external machine whose owner had kindly granted
> permission to do that.
We could arrange something for this if you're willing to try this yourself
on a tru64 box. I already did this for other package developers before...
> If you find that the sources need some specific fix to continue building
> on Tru64, I ask you to file a bug and send that fix.
If I could figure out the fixes, I would gladly do this, but I'm the one in
need of those fixes, as I'm stuck not being able to figure them out.
I already found quite a few tweaks to allow building a lot more, such as
using the -UHAVE_FESETROUND flag to work around an issue and with 5.1.33 I
had figured out that I needed -D_POSIX_PII_SOCKET and that worked then to
allow building to finish. Unfortunately I was getting a huge amount of those
unaligned access warnings and then sometimes a core dump (with 5.1.33).
> (As I don't have access to a Tru64, and am given other tasks, I cannot
> do such research myself.)
If you're willing, I can work something out for that.
>> I just upgraded my compilers, both cc and cxx to the latest and the errors
>> are still there...
>
> I still suspect it is a case of the header files not being accessed.
We'll find out shortly, I have an other build going right now and I'm saving
the logs.
Thanks,
--
Didier Godefroy
mailto:d...@ulysium.net
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
