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: "
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
incur
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 conta
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
> 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
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 libra
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 ob
> 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
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
circumst
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
- O
10 matches
Mail list logo
