I tried to complile 2.6.0 of this mod on OS X 10.3.5 with apache 1.3.x
when i used the apxs line in the readme file it returend a comman line error. I altered the line and it compiled. I want to know how my alteration would affect the module.
original : apxs -c -D -lmysqlclient -lm -lz mod_auth_mysql.o
working ver : apxs -c -D lmysqlclient -lm -lz mod_auth_mysql.o
thanks
Drew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I'm surprised the second version worked...
The actual problem here is the -D parameter is not necessary at all. It's left over from a couple of other examples I was going to put in the README file, but decided not just for simplicity.
The correct line should be (if I can type correctly :-) ):
apxs -c -lmysqlclient -lm -lz mod_auth_mysql.o
Sorry for the typo.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After I built that .pkg, I thought i'd do it all neat from the beginning so I used the apxs line you indicated above. However it only worked when I defined the -L and -I options correctly.
The OS X installer should alter the http.conf correctly now.
Drew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've looked at what would be required to have the httpd.conf auto-edited and it's a rather simple process (determined from examining the php source files that already do this)
I truly believe a configure script would uncomplicate the building and installation of this DSO but the author believes it's overkill.
While I have found problems with the source and corrected them in my copy, I cannot say if the author will pass along these changes to you.
I'll keep an eye on this DSO for future improvements and create a proper install script that removes the guesswork so I can continue to update my various platforms automatically without requiring any additional knowledge other than typing './configure; make; make install' to make it work reducing my debuging time to just going through the DSO source code.
I like complicated things done in a simplistic manner.
Hearing about a lot of installation issues based on the lack of knowledge of what is being done or users who have no real clue what to do other than following instructions they don't understand gives validity to the configure script but is not really my place other than my own benefit.
I don't really have the time to devote to a discussion on this DSO and I thought that my debugging efforts would be appreciated and passed along but it appears to be a struggle for this to occur.
if your platform is RCF compliant in it's communication with this module, you will find it's performance degraded due to the name conflict
It is my hopes that these changes while to most appear cosmetic. do get passed along to you but this is up to the author and beyond my control.
-- Dale
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
apxs can already add the LoadModule command to httpd.conf - no scripting is necessary. And even if the user must do this manually, it is a single line of code.
However, neither apxs nor configure can add the necessary entries to the <Directory> entries in httpd.conf (or .htaccess files). This is different on every installation.
As I indicated before, in addition, a configuration script adds much unnecesssary complication to the installation. The current installation requires only two commands (which could actually be done in one), and the locations of three directories. A configuration script will require the knowledge of one directory - and three commands.
As to the changes you have suggested. we will be happy to consider them if you can point us to the RFCs which are being violated. We want the module to be compliant with all formal guidelines, but I have not found any supporting your statements. Of course, I am not familiar with every RFC, and could have missed it.
Looking at both the module and Apache code, I can see no reason the current naming conventions should cause any problems.
Your debugging efforts are appreciated, as are everyones. And if there is a problem, we want to fix it.
Thanks,
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi,
I tried to complile 2.6.0 of this mod on OS X 10.3.5 with apache 1.3.x
when i used the apxs line in the readme file it returend a comman line error. I altered the line and it compiled. I want to know how my alteration would affect the module.
original : apxs -c -D -lmysqlclient -lm -lz mod_auth_mysql.o
working ver : apxs -c -D lmysqlclient -lm -lz mod_auth_mysql.o
thanks
Drew
Drew,
Actually, I'm surprised the second version worked...
The actual problem here is the -D parameter is not necessary at all. It's left over from a couple of other examples I was going to put in the README file, but decided not just for simplicity.
The correct line should be (if I can type correctly :-) ):
apxs -c -lmysqlclient -lm -lz mod_auth_mysql.o
Sorry for the typo.
Jerry
Hey Jerry,
After I built that .pkg, I thought i'd do it all neat from the beginning so I used the apxs line you indicated above. However it only worked when I defined the -L and -I options correctly.
The OS X installer should alter the http.conf correctly now.
Drew
On OS X 10.2.6 i used
apxs -c -D -lmysqlclient -lm -lz -I/usr/include/mysql -L/usr/lib/mysql mod_auth_mysql.c
and got:
gcc -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite -g -Os -pipe -DHARD_SERVER_LIMIT=2048 -DEAPI -DSHARED_MODULE -I/usr/include/httpd -I/usr/include/mysql -D-lmysqlclient -c mod_auth_mysql.c
cc -bundle -undefined suppress -flat_namespace -Wl,-bind_at_load -o mod_auth_mysql.so mod_auth_mysql.o -L/usr/lib/mysql -lm -lz
any ideas on how I can compile this?
Please see the other messages in this thread and this forum. The problem is a typo in the README file.
Jerry
Nobody/Anonymous - nobody
you compiled it, just issue the instal command:
apxs -i mod_auth_mysql.so
and edit your httpd.conf file as directed.
Of course, something may be released in the future to alleviate this building problem so keep an eye on the project for such changes.
-- Dale
I've looked at what would be required to have the httpd.conf auto-edited and it's a rather simple process (determined from examining the php source files that already do this)
I truly believe a configure script would uncomplicate the building and installation of this DSO but the author believes it's overkill.
While I have found problems with the source and corrected them in my copy, I cannot say if the author will pass along these changes to you.
I'll keep an eye on this DSO for future improvements and create a proper install script that removes the guesswork so I can continue to update my various platforms automatically without requiring any additional knowledge other than typing './configure; make; make install' to make it work reducing my debuging time to just going through the DSO source code.
I like complicated things done in a simplistic manner.
Hearing about a lot of installation issues based on the lack of knowledge of what is being done or users who have no real clue what to do other than following instructions they don't understand gives validity to the configure script but is not really my place other than my own benefit.
I don't really have the time to devote to a discussion on this DSO and I thought that my debugging efforts would be appreciated and passed along but it appears to be a struggle for this to occur.
if your platform is RCF compliant in it's communication with this module, you will find it's performance degraded due to the name conflict
It is my hopes that these changes while to most appear cosmetic. do get passed along to you but this is up to the author and beyond my control.
-- Dale
Dale,
apxs can already add the LoadModule command to httpd.conf - no scripting is necessary. And even if the user must do this manually, it is a single line of code.
However, neither apxs nor configure can add the necessary entries to the <Directory> entries in httpd.conf (or .htaccess files). This is different on every installation.
As I indicated before, in addition, a configuration script adds much unnecesssary complication to the installation. The current installation requires only two commands (which could actually be done in one), and the locations of three directories. A configuration script will require the knowledge of one directory - and three commands.
As to the changes you have suggested. we will be happy to consider them if you can point us to the RFCs which are being violated. We want the module to be compliant with all formal guidelines, but I have not found any supporting your statements. Of course, I am not familiar with every RFC, and could have missed it.
Looking at both the module and Apache code, I can see no reason the current naming conventions should cause any problems.
Your debugging efforts are appreciated, as are everyones. And if there is a problem, we want to fix it.
Thanks,
Jerry