Hi Didier, Walter, all!
Didier Godefroy wrote:
> on 4/28/09 10:01 AM, walter harms at wha...@bfs.de 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.
>
>> but i run mysql on 64bit Intel therefore i assume that mysql is 64bit clean.
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.
>
> There must be something wrong because when I built 5.1.33 earlier, it caused
> a huge amount of "unaligned access" warnings, but I had built that one with
> gcc and I was trying to build it using cc/cxx to see of that problem would
> go away...
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.
>
>> What you are missing is the posix thread library. On linux this is with
>> glibc.
>
> Actually, I'm not missing it, and that's what makes no sense, if you read my
> post, I only get the 2 errors on those 2 identifiers, which are defined in
> the posix thread library pthread.h which is in /usr/include on tru64 and
> that is obviously found and used because none of the other identifiers
> defined in it are coming up as undefined.
> I did some testing by changing the call in log.h to pthread_mutex_unlock,
> which causes the undefined error into pthread_mutex_lock and that error went
> away, so pthread_mutex_lock is defined but not pthread_mutex_unlock and
> they're both (and many others) defined in pthread.h
I'm speculating a bit:
- The message says "undefined", so it claims the header file(s) used
don't include the function name.
- 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.
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.
The plain "make" should get all settings etc from the configured
Makefile, so it shouldn't need any options.
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.
>
>> 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).
>
>> The mysql documentation says that True64 need special options to configure:
>> http://dev.mysql.com/doc/refman/5.1/en/alpha-dec-unix.html
>
> I already had looked at this and I do have all the right flags. I was able
> to build 5.1.33 and not 5.1.34, so something may have changed.
Sure, 5.1.34 had changes over 5.1.33, but these versions are
sufficiently close to each other that there is a chance to find the one
causing it.
>
>> If you find more issues please update the mysql documentation. These days
>> there is
>> a monoculture of intelboxes and linux but good programms should be tested on
>> more.
>
> It's Tru64 that is being neglected too much these days, we are still many
> users of it and it won't go away, but the support for it is lagging. And it
> seems posting on the mysql list about tru64 doesn't trigger much interest
> unfortunately.
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.
However, demand of binaries for Tru64 had gone down so much that
commercially it did not make sense to continue this.
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.
(As I don't have access to a Tru64, and am given other tasks, I cannot
do such research myself.)
I will see to apply such fixes to the sources - assuming they do not
cause trouble on other platforms, the chances are good.
> 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.
Regards and HTH,
Jörg
--
Joerg Bruehe, MySQL Build Team,
joerg.bru...@sun.com
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
