List:MySQL++« Previous MessageNext Message »
From:Robert Simmons Date:February 23 2009 2:24pm
Subject:Re: libmysqlpp.so on a 64bit platform
View as plain text  
The problem I was encountering was not upon building the application,  
but on running the built application. I have my IDE set to -L and -l  
all the correct locations upon build, but if the OS then cant find  
that when it comes to runtime the application won't run. My only  
solution was to either build MySQL++ into the /usr/lib64 directory so  
that when my application runs, it finds the libraries there - or to  
symlink the MySQL++ libraries from their directory, back into /usr/ 
lib64.

-Robert.

On 23 Feb 2009, at 14:21, Jim Graf wrote:

> I'm not sure if I'm following this right, but it has been my long  
> experience
> that third party applications and library's  have no business in an OS
> specific location, but it is just a policy and not a requirement,  
> although a
> very good policy.
>
> But if that is the policy, where to put 3rd party apps/libs is up to  
> the SA
> or developer. In that case, autoconf supplies sufficient resources,  
> such as
> --prefix, --libdir, etc.
>
> What that does is effectively take the build/install complexity away  
> from
> the 3rd party and push it to the user. So I compile and install some  
> 3rd
> party lib where ever I think it ought to be and then create a .pc  
> file for
> that build/install. When I build my apps against the third party -  
> mysql++,
> boost regex,... - I need to tool my configure.ac to find these things.
>
>
> ---------------------------------------------------------------------------------------
> PKG_PROG_PKG_CONFIG([0.22])
> # mysql++ library
> case "$target" in
>  *-solaris*)
>    case "$vendor" in
>      gnu) # using GNU Compiler
>        export PKG_CONFIG_PATH="/jgdata/Reticle/share/pkgconfig"
>        PKG_CHECK_MODULES([MYSQLPP], [mysql++-gnu >= 3.0.3])
>      ;;
>      sun) # using SUN Compiler
>        export PKG_CONFIG_PATH="/jgdata/Reticle/share/pkgconfig"
>        PKG_CHECK_MODULES([MYSQLPP], [mysql++-sun >= 3.0.3])
>      ;;
>    esac
>  ;;
> etc....
>
> ---------------------------------------------------------------------------------------
>
> And the hand created .pc file:
>
> prefix=/usr/lang/local/MYSQL/mysql++-3.0.3
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${exec_prefix}/include/mysql++
>
> Name: libmysqlpp
> Description: MySQL++ Access library
> Version: 3.0.3
> Libs: -L${libdir}  -lmysqlpp
> Cflags: -I${includedir}
>
> ---------------------------------------------------------------------------------------
>
> I have to admit, putting third party apps/libs in a non OS location  
> makes
> the developers life more complicated, dealing with -R...-L... or
> -W,-rpath... insanities, maybe even choosing the right .pc file, but  
> it is
> the right policy from a systems POV.
>
> A long winded way of my saying I don't think mysql++ should attempt to
> figure out if it is going to be compiled 32 or 64 bit or where to  
> install
> itself. Everything exists now in autoconf to do that. Keep the third  
> party
> lib simple and push the build/install complexity to the user.
>
> -jim
>
> PS. using pkg-config makes life much nicer.
>
> On Sun, Feb 22, 2009 at 6:46 PM, Warren Young <mysqlpp@stripped>  
> wrote:
>
>> On Feb 22, 2009, at 9:38 AM, Robert Simmons wrote:
>>
>> 64bit applications look for /usr/lib64 normally.
>>>
>>
>> That's just one way it's done, and that's not even universal on  
>> Linux.
>> Just off the top of my head, I've recalled four different library  
>> path
>> schemes for coping with the 32/64 bit problem, and I'm doubtless  
>> missing
>> others.  There's no "right" answer for MySQL++ to hard code.  It  
>> doesn't
>> help that the build files we maintain are two abstraction layers  
>> above the
>> OS.
>>
>> The best we could do is guess somehow.  Are you aware of another
>> autoconf-based package that guesses this correctly, which isn't
>> Linux-specific?  We have to support OS X and Solaris at least, both  
>> of which
>> cope with the 32/64 bit problem differently.
>>
>> I realize you have a fix now, Robert, but we should discuss ways to  
>> do
>> something clever to ease others' troubles on this in the future.
>>
>> --
>> MySQL++ Mailing List
>> For list archives: http://lists.mysql.com/plusplus
>> To unsubscribe:
>> http://lists.mysql.com/plusplus?unsub=1
>>
>>

Thread
libmysqlpp.so on a 64bit platformRobert Simmons22 Feb
  • Re: libmysqlpp.so on a 64bit platformRemi Collet22 Feb
  • Re: libmysqlpp.so on a 64bit platformWarren Young23 Feb
    • Re: libmysqlpp.so on a 64bit platformJim Graf23 Feb
      • Re: libmysqlpp.so on a 64bit platformRobert Simmons23 Feb
        • Re: libmysqlpp.so on a 64bit platformJim Graf23 Feb
        • Re: libmysqlpp.so on a 64bit platformJonathan Wakely24 Feb
      • Re: libmysqlpp.so on a 64bit platformWarren Young24 Feb