List:General Discussion« Previous MessageNext Message »
From:Didier Godefroy Date:April 28 2009 6:04pm
Subject:Re: Building 5.1 on Tru64 5.1b
View as plain text  
on 4/28/09 3:30 PM, Joerg Bruehe at Joerg.Bruehe@stripped uttered the

>>>> 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
> "".
> 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".


> - 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

#  pragma extern_prefix "__"
# else
#  define pthread_mutex_destroy __pthread_mutex_destroy
# endif
extern int pthread_mutex_destroy (pthread_mutex_t*);
# pragma extern_prefix ""
#  pragma extern_prefix "__"
# else
#  define pthread_mutex_lock __pthread_mutex_lock
# endif
extern int pthread_mutex_lock (pthread_mutex_t*);
# pragma extern_prefix ""

#  pragma extern_prefix "__"
# else
#  define pthread_mutex_unlock __pthread_mutex_unlock
# endif
extern int pthread_mutex_unlock (pthread_mutex_t*);
# pragma extern_prefix ""

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 "" 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.


Didier Godefroy

Building 5.1 on Tru64 5.1bDidier Godefroy27 Apr
  • Re: Building 5.1 on Tru64 5.1bwalter harms28 Apr
    • Re: Building 5.1 on Tru64 5.1bDidier Godefroy28 Apr
      • Re: Building 5.1 on Tru64 5.1bJoerg Bruehe28 Apr
        • Re: Building 5.1 on Tru64 5.1bJoerg Bruehe28 Apr
        • Re: Building 5.1 on Tru64 5.1bDidier Godefroy28 Apr