Proper way to modify env in qpr file?

Hello,

I’m putting together the package for MySQL, and I need to be
able to modify the LIBPATH variable. MySQL puts its libraries
into /usr/lib/mysql, which is not normally searched. I thought
that using something like:

setconf LIBPATH getconf LIBPATH:/usr/lib/mysql

would be a good choice, but that only works until the next reboot.
How should I go about adding to LIBPATH in such a way that
it persists through a reboot, bearing in mind that I need to do this
within a script. Also, how should I then remove this path element
when somebody uninstalls the MySQL package? I don’t think that
fiddling with /etc/rc.d/rc.local is really appropriate, or particularly
trustworthy.

Thanks,
Andrew

There is an rpath option you can pass to the linker for all the MySQL
binaries to tell them to search in a specific location in addition to the
system configured ones. That is what openqnx’s XFree86 builds are doing.

chris


Andrew Thomas <andrew@at.cogent.dot.ca> wrote:

Hello,

I’m putting together the package for MySQL, and I need to be
able to modify the LIBPATH variable. MySQL puts its libraries
into /usr/lib/mysql, which is not normally searched. I thought
that using something like:

setconf LIBPATH getconf LIBPATH:/usr/lib/mysql

would be a good choice, but that only works until the next reboot.
How should I go about adding to LIBPATH in such a way that
it persists through a reboot, bearing in mind that I need to do this
within a script. Also, how should I then remove this path element
when somebody uninstalls the MySQL package? I don’t think that
fiddling with /etc/rc.d/rc.local is really appropriate, or particularly
trustworthy.

Thanks,
Andrew


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Chris McKillop” <cdm@qnx.com> wrote in message
news:at855o$der$1@nntp.qnx.com

There is an rpath option you can pass to the linker for all the MySQL
binaries to tell them to search in a specific location in addition to the
system configured ones. That is what openqnx’s XFree86 builds are doing.

I understand that this would make the mysql server run, but what does
a developer do when he creates a program that links the
MySQL client library? The goal here is that if somebody has installed the
MySQL package then a developer’s attempts to compile, link and run
will succeed. I was hoping there was a way to add the various MySQL
bits (/usr/include/mysql, /usr/lib/mysql) to the default paths. When I
install a MySQL rpm in Linux, it alters /etc/ld.so.conf, but leaves me
searching for headers and libraries when compiling and linking. That’s
really pretty lame, and QNX doesn’t even have /etc/ld.so.conf.

I can put the package together without this, but it seems so … unfinished.

Cheers,
Andrew

Well, if mysql wants to install itself into all of these non-standard and
mysql specific spots then well, it is going to be hard to work with. I
have never understood why they can’t just live in the normal locations with
everything else. You could probably get the configure script to put
everything in the right spot.

chris


Andrew Thomas <andrew@at.cogent.dot.ca> wrote:

“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:at855o$der$> 1@nntp.qnx.com> …
There is an rpath option you can pass to the linker for all the MySQL
binaries to tell them to search in a specific location in addition to the
system configured ones. That is what openqnx’s XFree86 builds are doing.

I understand that this would make the mysql server run, but what does
a developer do when he creates a program that links the
MySQL client library? The goal here is that if somebody has installed the
MySQL package then a developer’s attempts to compile, link and run
will succeed. I was hoping there was a way to add the various MySQL
bits (/usr/include/mysql, /usr/lib/mysql) to the default paths. When I
install a MySQL rpm in Linux, it alters /etc/ld.so.conf, but leaves me
searching for headers and libraries when compiling and linking. That’s
really pretty lame, and QNX doesn’t even have /etc/ld.so.conf.

I can put the package together without this, but it seems so … unfinished.

Cheers,
Andrew


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

My suggestion would be to create a MySql.sh file and put it in
/etc/profile.d/

You can set whatever XXPATH vars you like in there.

That will get executed for every user login.

Rob Rutherford

“Chris McKillop” <cdm@qnx.com> wrote in message
news:at8cid$i5e$2@nntp.qnx.com

Well, if mysql wants to install itself into all of these non-standard and
mysql specific spots then well, it is going to be hard to work with. I
have never understood why they can’t just live in the normal locations
with
everything else. You could probably get the configure script to put
everything in the right spot.

chris


Andrew Thomas <> andrew@at.cogent.dot.ca> > wrote:
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:at855o$der$> 1@nntp.qnx.com> …
There is an rpath option you can pass to the linker for all the MySQL
binaries to tell them to search in a specific location in addition to
the
system configured ones. That is what openqnx’s XFree86 builds are
doing.

I understand that this would make the mysql server run, but what does
a developer do when he creates a program that links the
MySQL client library? The goal here is that if somebody has installed
the
MySQL package then a developer’s attempts to compile, link and run
will succeed. I was hoping there was a way to add the various MySQL
bits (/usr/include/mysql, /usr/lib/mysql) to the default paths. When I
install a MySQL rpm in Linux, it alters /etc/ld.so.conf, but leaves me
searching for headers and libraries when compiling and linking. That’s
really pretty lame, and QNX doesn’t even have /etc/ld.so.conf.

I can put the package together without this, but it seems so …
unfinished.

Cheers,
Andrew


\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

andrew@at.cogent.dot.ca sed in <at888p$fuu$1@inn.qnx.com>:

I understand that this would make the mysql server run, but what does
a developer do when he creates a program that links the
MySQL client library? The goal here is that if somebody has installed the
MySQL package then a developer’s attempts to compile, link and run
will succeed. I was hoping there was a way to add the various MySQL
bits (/usr/include/mysql, /usr/lib/mysql) to the default paths. When I

It’s that developer’s job to add LD_RUN_PATH=/usr/lib/mysql
during the build, not MySQL vendor’s.

So you don’t have to and shouldn’t muck with “default search paths”.

Although mentioning in the release note etc is worth it cuz
still lots of “developers” isn’t aware of ELF RPATH things.
(probably because Linux ld.so.conf is still alive)


For QNX, it doesn’t hurt much to dump them into standard /usr/lib because
the actual image will be /pkgs/repository/public/mysql/*/opt/lib whatever
and uninstall is cheesy and “real” /usr/lib isn’t polluted at all.

kabe

<kabe@sra-tohoku.co.jp> wrote in message
news:021212112747.M025783578@corvus.soft.iwate-pu.ac.jp

andrew@at.cogent.dot.ca > sed in <at888p$fuu$> 1@inn.qnx.com> >:

I understand that this would make the mysql server run, but what does
a developer do when he creates a program that links the
MySQL client library? The goal here is that if somebody has installed
the
MySQL package then a developer’s attempts to compile, link and run
will succeed. I was hoping there was a way to add the various MySQL
bits (/usr/include/mysql, /usr/lib/mysql) to the default paths. When I

It’s that developer’s job to add LD_RUN_PATH=/usr/lib/mysql
during the build, not MySQL vendor’s.

So you don’t have to and shouldn’t muck with “default search paths”.

I was talking about default search paths for .so, .a and .h files, without
which a user of the MySQL libraries will have to explicitly code the
locations of .so, .a and .h files into his makefiles. I don’t understand
your
comment about the MySQL vendor.

For QNX, it doesn’t hurt much to dump them into standard /usr/lib because
the actual image will be /pkgs/repository/public/mysql/*/opt/lib whatever
and uninstall is cheesy and “real” /usr/lib isn’t polluted at all.

MySQL is not careful about naming its libraries and headers because
it believes it will be living in its own subdirectories. There is a (small)
opportunity for library and header name collisions.

I agree that it should be possible to put MySQL’s headers and libs in
‘expected’ places. Perhaps that’s what I’ll do, and let the user
beware if they get superceded. Bleh.

Cheers,
Andrew

andrew@at.cogent.dot.ca sed in <atapjf$db0$1@inn.qnx.com>:

I was talking about default search paths for .so, .a and .h files,
I was talking about default search paths for .so, .a and .h files.



without
which a user of the MySQL libraries will have to explicitly code the
locations of .so, .a and .h files into his makefiles.
Generally those people using the MySQL libraries should find out

where they are located and tune the Makefile appropriately.
It isn’t cranky or unusual; perfectly normal.
Although they may want to automate finding them out by
GNU autoconf (configure).

I don’t understand
your comment about the MySQL vendor.
In this case YOU are the MySQL vendor (of the QNX package).



MySQL is not careful about naming its libraries and headers because
it believes it will be living in its own subdirectories. There is a (small)
opportunity for library and header name collisions.

I agree that it should be possible to put MySQL’s headers and libs in
‘expected’ places. Perhaps that’s what I’ll do, and let the user
beware if they get superceded. Bleh.

From your Requirements will deduce that you can never make everyone happy.

There’s two ways to go:
*) Stick to MySQL’s way, and install them where MySQL original distro
likes to.
*) Make it QNX-friendly by following QNX customs; that is
usually installing in /usr/lib etc (dunno about /usr/include)
It’s worth noting that reason to install them in /usr/lib etc
is different than that of Linux.

Either has pros and cons and in someway “correct”.

kabe