Re: 3.23.54a - Solaris 9/gcc 2.95.3 compile problem
I've run into this if a previous build attempt aborted due to a bad LD_(LIBRARY|RUN)_PATH where I fixed the LD variable, and re-tried the build. Starting with a fresh copy of the source (not distclean, fresh from tarfile), always solved my problem. -=| Ben - Original Message - From: "Len Rose" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 19, 2003 8:57 AM Subject: 3.23.54a - Solaris 9/gcc 2.95.3 compile problem > > Has anyone run into this? I did a search on the web site > looking for information before posting, didn't see > anything.. > > 3.23.54a - Compiling with gcc 2.95.3, Solaris 9 sparc.. > > > > # snip > Making all in sql > make all-recursive > Making all in share > source='sql_lex.cc' object='sql_lex.o' libtool=no \ > depfile='.deps/sql_lex.Po' tmpdepfile='.deps/sql_lex.TPo' \ > depmode=gcc /bin/bash ../depcomp \ > ++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/opt/local\"" -DDATADIR="\"/var/ data\"" -DSHAREDIR="\"/opt/local/share/mysql\"" -DHAVE_CONFIG_H -I. -I. -I .. -I./../include -I./../regex -I. -I../include -I.. -I. -O3 -DDBUG_OF F -fno-implicit-templates -fno-exceptions -fno-rtti -DHAVE_RWLOCK_T -c -o sql_lex.o `test -f sql_lex.cc || echo './'`sql_lex.cc > sql_lex.cc: In function `void lex_init()': > sql_lex.cc:85: `symbols' undeclared (first use this function) > sql_lex.cc:85: (Each undeclared identifier is reported only once > sql_lex.cc:85: for each function it appears in.) > sql_lex.cc:87: `sql_functions' undeclared (first use this function) > sql_lex.cc: In function `int find_keyword(LEX *, unsigned int, bool)': > sql_lex.cc:168: implicit declaration of function `int get_hash_symbol(...)' > sql_lex.cc:168: initialization to `SYMBOL *' from `int' lacks a cast > *** Error code 1 > make: Fatal error: Command failed for target `sql_lex.o' > # snip > > Thanks > > Len > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysql compile problem under Solaris 9
I've found that previous build-attempts that have failed (IE did you have a bad/nonexistant LD_LIBRARY_PATH, fix it, and then try 'make' again?) cause this, and even a make distclean doesn't fix it. Try starting from a freshly untarred source ... that's always done it for me. -=| Ben - Original Message - From: "Andy Elmer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 10:58 AM Subject: mysql compile problem under Solaris 9 > I have tried compiling the latest 3.23 version of mysql under Solaris 9 > using gcc 3.2 and keep getting the following error: > > g++ -DMYSQL_SERVER > -DDEFAULT_MYSQL_HOME="\"/usr/local/mysql\"" > -DDATADIR="\"/usr/local/mysql/var\"" > -DSHAREDIR="\"/usr/local/mysql/share/mysql\"" > -DHAVE_CONFIG_H -I./../include -I./../regex >-I. -I../include -I.. -I.-O3 -DDBUG_OFF > -fno-implicit-templates -fno-exceptions -fno-rtti -DHAVE_RWLOCK_T -c > sql_lex.cc > sql_lex.cc: In function `void lex_init()': > sql_lex.cc:85: `symbols' undeclared (first use this function) > sql_lex.cc:85: (Each undeclared identifier is reported only once for > each >function it appears in.) > sql_lex.cc:87: `sql_functions' undeclared (first use this function) > sql_lex.cc: In function `int find_keyword(LEX*, unsigned int, bool)': > sql_lex.cc:168: `get_hash_symbol' undeclared (first use this function) > make[3]: *** [sql_lex.o] Error 1 > make[3]: Leaving directory `/opt/build/mysql-3.23.53/sql' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/opt/build/mysql-3.23.53/sql' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/opt/build/mysql-3.23.53' > make: *** [all-recursive-am] Error 2 > > I have found other postings with this same issue through google > searches, however, I never came across a resolution. Here are my > configure options: > CFLAGS=-O6 ./configure --prefix=/usr/local/mysql --with-low-memory > > Any sugguestions? Thanks! > > Andy > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Problems installing on Solaris/Intel
I've compiled and installed this on my Solaris8/Intel box a few times without a hitch.. I don't recall seeing what version of Solaris you're running.. ? I also compiled with just ./configure - I didn't bother with the other options.. although that might be asking for trouble under certain circumstances... I don't have the source in front of me to check but I seem to recall being able to compile specifically withOUT curses support? Is your ncurses library up to date? Changing which curses libs to use won't affect this issue - the issue is a header/include problem, not a library problem. If that doesn't help, let me know and I'll try to suggest other things as well as check out my installation -=| Ben Resending: sql,query - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: List of Linked Libraries for 3.23.52
> I have been running MySQL in 32-bit mode on Solaris for about a year now.
> I've been attempting to compile 3.23.52 in 64 bit mode using the Sun
> Workshop 6 Update 2 compiler. Everything works/compiles great until it's
Any reason to go 64-bit? I've compiled 64-bit myself and it seems to work
for the rudimentary stuff I was doing .. FWIW, the MySQL docs state that
64-bit compilations aren't supported ... There may be bugs/corruption that
you'll run into ...
> link time. I think the libtool or /usr/ccs/bin/ld thinks either:
> - my system cannot run 64 bit apps
> - there's a 32-bit library out there that cannot mate with a
> 64-bit library
Based on the messages below, it's a 32/64 mismatch.
> Is there a way to get libtool to tell me what libraries it is using and
> where it is looking? I think if I had that list I could audit it for
32-bit
> libs.
> (I suspect it may be curses, but I cannot tell where it is looking)
>
> Here's the barf from the shell:
>
> /bin/sh ../libtool --mode=link /opt/SUNWspro/bin/CC -O3
> -DDBUG_OFF -DHAVE_CURSES_H -I/opt/src/mysql-3.23.52/include
> -DHAVE_RWLOCK_T -o mysql mysql.o readline.o sql_string.o
> completion_hash.o ../readline/libreadline.a -lcurses
> ../libmysql/libmysqlclient.la -lz -lgen -lsocket -lnsl -lm
> /opt/SUNWspro/bin/CC -O3 -DDBUG_OFF -DHAVE_CURSES_H
> -I/opt/src/mysql-3.23.52/include -DHAVE_RWLOCK_T -o .libs/mysql mysql.o
> readline.o sql_string.o completion_hash.o ../readline/libreadline.a
> -lcurses ../libmysql/.libs/libmysqlclient.so -lz -lgen -lsocket -lnsl -lm
> -lz -lgen -lsocket -lnsl -lm -R/opt/local/lib/mysql
> ld: warning: file ../readline/libreadline.a(readline.o): wrong ELF class:
> ELFCLASS64
>From the ld man page:
No command-line option is required to distinguish 32-bit or
64-bit objects. The link-editor uses the ELF class of the
first input relocatable file it sees to govern the mode in
which it will operate.
The error message, combined with the above knowledge, means ld is in 32 bit
mode and the 64-bit class of libreadline is a mismatch. I don't know what
the first relocatable file is in your CC line is, so one way to determine
what's going on is to set the LD_OPTIONS environment variable to the proper
switch ('-64' I believe) that forces 64-bit mode and retry the compile.
Then you'll see complaints about the 'offending' 32-bit libraries which will
help you narrow down the problem. You may need to do things like make
/usr/lib/sparcv9 come AHEAD of /usr/lib so that the linker attempts the
system's 64-bit libs first. Offhand I'm not sure if setting your LDFLAGS
will do the trick as I'm not sure if that's used before the default /usr/lib
or not. It's been a while since I did this and I no longer have access to
the machine to test... Perhaps toying with LD_LIBRARY_PATH (and make
LD_RUN_PATH match) environment variables will work .. IE setting them to
'/usr/lib/sparcv9:/usr/lib'
[snip]
HTH,
-=| Ben
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Storing 100 million images in the database
Mmm.. filter goodness. Trying again with the required words: sql query > ... along the lines of using the database as a pointer to the real file in a > normal filesystem that others have suggested.. may I add the idea of using a > 'hashed' directory structure such that you don't end up with an obviously > messy (and *very* slow) directory of files... unless # of inodes becomes an > issue... > something like > > /imageroot/e/x/a/m/example.jpg > > you could base it off filename, or the index number, or something along > those lines.. as long as it's sufficiently random or distributed... > > -=| Ben > > > > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: "BUG": 'strend' function in libmysql needs to be private
I was about to email bugs/lists back today to basically say I've found a reasonable workaround.. I'll respond to your message though in case you see something that needs attention ... > strend() is a function we use a lot in the MySQL client code and is > thus included in the libmysqlclient library. Yeah I've come to realize this .. the 'mysql' client binary started complaining about not finding strend :-) > I can't see how csh could affect this in any way as csh doesn't have > anything directly to do with shared libraries. (Except of course if > you are trying to load a shared library inside csh).using a patched csh I'm writing an NSS library, so when csh does ~username expansion, calling getpwnam, the system automatically loads my library in order to find the user in MySQL. csh itself has nothing to do with loading the library. > Which public library is it that has a conflicting function ? > (I have used Solaris a lot and never seen this problem before) I don't know, actually. I haven't been able to find it since everything's stripped and whatnot. I may just not be using the right tools to find it. I tried running nm/ldd to find it to no avail. > What is it that core dumps; csh or your application ? > Does your application work if you are running 'sh' ? The error happens inside the MySQL client library (since the library starts using the wrong 'strend'), filtering back down to 'csh' which then dumps. tcsh, bash, etc work fine.. it's only csh. I've managed to get around the problem by linking my library with '-B group' in order to keep the symbols from leaking around where they shouldn't be. I found that there were other symbols being stomped on, too .. so it wasn't just 'strend' anymore .. so my workaround seems the best choice.. and I guess we can consider the matter resolved... Thanks! -=| Ben - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Can't link with C API
> That path isn't where mysql is installed. I checked the paths; my makefile > has the correct path. CC can find the header files, and the linker can find > the lib (using truss I can see the linker open the file). > > I'm not sure where the --prefix cam frome. Is that a compile-time option? > I didn't actually compile the MySQL DB myself. I downlaoded the Solaris > tar. The --prefix came from your mysqlbug information (near the bottom). Can you type this command in and paste the exact output here? /usr/bin/ldd /work/doctools/mysql-3.23.52/lib/libmysqlclient.so It might also be helpful to cut-n-paste the entire output of 'make' so we can verify things look the way they should. Note: You should also have '-R /work/doctools/mysql-3.23.52/lib' since Solaris is not going to search that directory for the MySQL library at runtime. Add that to your MYSQLLIBS section. This won't fix the compilation issue, but you'll need it to run the 'TEST' program. -=| Ben - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Can't link with C API
Based on the prefix for your MySQL installation (--prefix=/usr/local/mysql '), you're not using the right paths. You need to set the -I to be where your mysql.h file is, and the -L to be where your libmysqlclient.so (or .a if compiling static) file is. I'd recommend trying the following values MYSQLFLAGS = -I/usr/local/mysql/include/mysql MYSQLLIBS = -L/usr/local/mysql/lib/mysql -lmysqlclient That may not be quite right - check for the locations of the above-mentioned files and adjust if need be. Good luck! -=| Ben - Original Message - From: "Steve Cogorno" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, September 07, 2002 12:19 AM Subject: Can't link with C API > >Description: > I must be missing something terribly obvious, but I cannot get > my client program to link. I get messages like this: > ild: (undefined symbol) mysql_free_result -- referenced in the text segment of dbinterface.o > > The reference manual says to make sure the -lmysqlclient and -L > settings are provided to the linker, which they are. I've > moved these around. I've tried setting the compile to static instead > of dynamic link. None of these seems to help. > > I'm using the SUNWspro/CC compiler. I've tried switching to gcc, > but I get the same result. > > I know that the linkers is finding the MySQL libraries because I can > see the libmysqlclient.a file being opened when I trace the process > with truss. > > I appreciate any advice you can provide! > > Here's the make file: > > CC = cc > > CFLAGS = -Dsvr4 -g > > MYSQLFLAGS = -I /work/doctools/mysql/include > MYSQLLIBS = -L /work/doctools/mysql-3.23.52/lib -lmysqlclient > > INCFLAGS = -I /usr/local/include > > > all: TEST > > clean: > rm *o TEST > > TEST: dbinterface.o TEST.o > $(CC) $(CFLAGS) $(INCFLAGS) $(MYSQLLIBS) dbinterface.o TEST.o -o TEST > > TEST.o: TEST.c > $(CC) $(CFLAGS) $(INCFLAGS) $(MYSQLFLAGS) -c TEST.c -o TEST.o > > dbinterface.o: dbinterface.c > $(CC) $(CFLAGS) $(INCFLAGS) $(MYSQLFLAGS) -c dbinterface.c -o dbinterface.o > 9 > > > >How-To-Repeat: > > >Fix: > > > >Submitter-Id: > >Originator: > >Organization: > Steve Cogorno > > > >MySQL support: none > >Synopsis: Can't link to API > >Severity: serious > >Priority: medium > >Category: mysql > >Class: support > >Release: mysql-3.23.52-max (Official MySQL-max binary) > >Server: ./mysqladmin Ver 8.23 Distrib 3.23.52, for sun-solaris2.8 on sparc > Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB > This software comes with ABSOLUTELY NO WARRANTY. This is free software, > and you are welcome to modify and redistribute it under the GPL license > > Server version 3.23.52-max > Protocol version 10 > Connection Localhost via UNIX socket > UNIX socket /tmp/mysql.sock > Uptime: 4 hours 46 min 41 sec > > Threads: 1 Questions: 452 Slow queries: 0 Opens: 675 Flush tables: 1 Open tables: 2 Queries per second avg: 0.026 > >Environment: > Compiled: Sun CC 5.0 > System: SunOS village 5.9 Generic sun4u sparc SUNW,Ultra-60 > Architecture: sun4 > > Some paths: /usr/bin/perl /usr/ccs/bin/make /net/suntools/export/tools/sparc/bin/gmake /net/suntools/export/tools/sparc/bin/gcc /ws/on81-tools/SUNWspro/SC5.0/bin//cc > GCC: Reading specs from /net/newsuntools.sfbay/export/tools/sparc/lib/gcc-lib/sparc-sun-solaris2.7/2 .95/specs > gcc version 2.95 19990728 (release) > Compilation info: CC='gcc' CFLAGS='-O3 -fno-omit-frame-pointer' CXX='gcc' CXXFLAGS='-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions - fno-rtti' LDFLAGS='' > LIBC: > -rw-r--r-- 1 root bin 1828460 Apr 6 12:46 /lib/libc.a > lrwxrwxrwx 1 root root 11 Jun 18 18:13 /lib/libc.so -> ./libc.so.1 > -rwxr-xr-x 1 root bin 855484 Apr 6 12:46 /lib/libc.so.1 > -rw-r--r-- 1 root bin 1828460 Apr 6 12:46 /usr/lib/libc.a > lrwxrwxrwx 1 root root 11 Jun 18 18:13 /usr/lib/libc.so -> ./libc.so.1 > -rwxr-xr-x 1 root bin 855484 Apr 6 12:46 /usr/lib/libc.so.1 > Configure command: ./configure --prefix=/usr/local/mysql '--with-comment=Official MySQL-max binary' --with-extra-charsets=complex --with-server-suffix=-max --enable-thr ead-safe-client --enable-local-infile --enable-assembler --disable-shared -- with-berkeley-db --with-innodb CC=gcc 'CFLAGS=-O3 -fno-omit-frame-pointer' 'CXXFLAGS=-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions - fno-rtti' CXX=gcc > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/
Re: More info: Strange memory leak problem (C API)
If I link the library with '-z nodelete' the leak goes away. The library doesn't get loaded and unloaded over and over again... >From the Solaris 'ld' man page -z nodelete Marks the object as non-deletable at runtime. The run- time processing of an object that contains this flag mimics that which occurs if the object is added to a process using dlopen(3DL) with the RTLD_NODELETE mode. and from dlopen: RTLD_NODELETE The specified object will not be deleted from the address space as part of a dlclose(). While this cures my problem, it seems it's an inappropriate bandaid.. I don't see wide use of this option upon a cursory 'net search ... And I don't know if this is a mysql problem or a solaris problem ... would dlopen()ing a library that's compiled with -lmysqlclient, allocating memory using a routine (mysql_init) from that included library, and then unloading the library cause a memory leak if the included (mysqlclient) library doesn't free certain other memory that's only initialized once mysql_init is called? IE does mysql_init do a one-time memory alloc that's never freed (but under normal circumstances doesn't cause a leak because the alloc'ed area is normally assumed to be around for the duration of the program)? So subsequent loads of the librarys cause this one-time memory alloc to be called over and over? This might need to go to some core MySQL folks unless someone here's familiar with the client library internals ... :-) Thanks! -=| Ben - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
More info: Strange memory leak problem (C API)
I've compiled debugging into the library .. now I figured the library was getting loaded/unloaded, but it didn't really come to mind until I ran it with debugging. My atomic tests (A standalone program that init's and closes) does NOT do this.. So, I'm wondering if the leak is somehow being incurred by constantly mmaping and un-mmaping the library even though the master process (the one calling getpwnam over and over) never exits - libmysqlclient is being dynamically loaded and unloaded over and over again. --- MYSQL_DEBUG found. libmysql started with the following: d:t:L:n:N:S:F --- 1: libmysql.c: 1664:1: >mysql_close 2: libmysql.c: 1700:1: mysql_close 2: libmysql.c: 1700:1: mysql_close 2: libmysql.c: 1700:1: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
