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 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
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 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
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 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
> 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
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
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
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
10 matches
Mail list logo