Re: [PHP-DEV] 4.3.0 Extension

[md]

Derick:

Yes, that would be an avenue of approach, but in this case, I only
have a single libphp4.so file on the apache server.

There are no "extra" shared libraries floating around.

What I will do is give it another try in a couple of days to get the
basic compiled ext_skel working again.

Then I will share some more notes.

Mark Diener

Derick Rethans wrote:
> 
> On Mon, 17 Feb 2003, md wrote:
> 
> > I will look for duplicates as you suggest.
> >
> > I noticed that you use the PHP_ARG_WITH( inside your website's config.m4
> > file.
> >
> > But if I wanted an internally embedded set of code instead of external
> > shared library, I could use PHP_ARG_ENABLE( instead.
> 
> That's not the difference. It's just that _WITH creates an extension
> that makes use of an external library, while _ENABLE doesn't do that.
> You can always install both styles of modules as shared or
> static (internal).
> 
> > My problem so far has been using PHP_ARG_ENABLE( in config.m4.
> >
> > Downloading the source tarball, going immediately to ext_skel,
> > buildconf, configure, and make has produced the aforementioned error
> > in apache.
> >
> > Somehow, I doubt the ext_skel utility would put 2 of the _confirm_X()
> > functions in the same module.
> >
> > Then comes how the module could be loaded twice when the same apache
> > server that runs 4.2.3 is also used to run 4.3.0.
> 
> Once statically and once as shared module perhaps?
> 
> > I also do not have any idea what the "phpize" is all about, for external
> > modules only?
> 
> phpize can be used to create shared modules out of the php source tree,
> which is often wanted during development. (it's about the same as using
> --with-testmodules=shared on your normal php configure line).
> 
> Derick
> 
> --
> Stop mad cowboy disease!
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
> 
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] 4.3.0 Extension

[md]

Hello:

I am new to your list, but a long time user of extensions in PHP.

I just met with complete failure trying to compile a working extension
in 4.3.0 under linux/apache

This is a pre-cursor to migrating my previous extensions to the new
version.

I tried just the basic ext_skel --extname=testmodulename to see if I
could
do that successfully and I could not.

During server load on apache, the zend_API.c - line 1058 -> if
(zend_hash_exists(TRUE) -> warning message
"PHP Warning: Function registration failed - duplicate name -
compile_testmodulemodule_confirm in Unknown on line 0"
"PHP Warning: testmodulename: Unable to register functions, unable to
load
in Unknown on line 0.

Now, the process has always been a little vague, the steps on the web
site are:

1) ./ext_skel --extname=testmodule

2) Edit config.m4 file to remove two dnl entries to ENABLE_ARG module 

3) ./buildconf

4) ./configure --with-mysql --with-apxs=/x  --enable-testmodulename

5) make Makefile and put the resulting shared library on the apache
server and run the httpd daemon and the above errors occur during apache
server load.

I am able to do the same things with 4.2.3 and it works fine.

Can someone tell me what specifically to edit in config.m4 to get
ext_skel to work? (The web site is vague about it)

Thanks,

Mark Diener


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] no longer urgent compilation question

[md]

I recently posted an urgent compilation question to the list
requesting information about linking in external shared libraries
to libphp4.so.

This issue is no longer urgent.

If one modifies the follwing line to /php/Makefile :

LTLIBRARY_LIBADD = $(LTLIBRARY_DEPENDENCIES) $(EXTRA_LIBS)
-lmysharedlibraryname

The unresolved references would be discovered at link time.

Unfortunately, this is probably not the place for me to instruct the
linker
to find the unresolved references for my specific module, but it gets
the job done.

I guess the m4 macro file config.m4,
but I cannot even begin to decipher the GNU m4 macro script,
so I will just stick to C code.

While I am sure the use of autoconf, automake, and libtool greatly
facilitate
the building of cross-platform PHP, those tools are just as obfuscate as
any I have
seen.  And reading the GNU documentation is just not productive.

Thanks for anyone who may respond to my earlier questions,

Mark Diener


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Urgent compilation question

[md]

Anyone within eyeshot of this message,
please read up. I posted last night with no
response this morning.

Environment: Linux, Redhat 6.2, PHP 4.0.4pl1

My ext_skel was command line looks like: php/ext/EXT_SKEL
--extname=mynewmodule

My configure line looks like: ./configure --with-mysql --with-apxs
--with-mynewmodule

I used EXT_SKEL to add embedded functions in libphp4.so to use with
apache.
Afterwards, when I add code that would
call functions in an external shared library, I get 
unresolved function references during compilation.

Where in the files generated by EXT_SKEL do I add references
to external shared libraries that reside in /lib.

For example, I would like to call functions in /lib/libm.so.6 from
inside libphp4.so?

Any response greatly appreciated?   

Mark Diener


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] EXT_SKEL question

[md]

Hello Rasmus and Zeev and all the others:

Back in March, I attempted to get to the bottom
self contained extensions.  I never succeeded at
doing that, but I was able to get embedded extensions
compiled and working.

Unfortunately, I lost a hard drive last week and my PHP development
environment went crash...  No source code lost, just environment.

In trying to rebuild my PHP dev environment, I have come across a sticky
issue
that you guys may be able to help me with.  I cannot remember how I
solved it
last time.

I am still using PHP 4.0.4.pl1 (not 4.0.6).  

After running: /php/ext/EXT_SKEL --extname=addmod, I discover
in the ext/ directory another directory named "addmod".  This 
extension compiles as embedded code into libphp4.so using:

../php/configure --with-mysql --with-apxs --with-addmod

Now, when I want to add code to addmod.c that would call functions
stored
in shared library /lib/libwhat.so, I find the compilation process
generates "definition"
errors for functions that reside with /lib/libwhat.so.

The important question is, what file and where within it do I add a
reference so that the linker can 
resolve the unknown definitions that are inside of /lib/libwhat.so or
any other shared library for that matter.

The syntax you would use to make the unresolved reference go away would
be very help as well.

Inside the addmod directory, there is addmod.c  php_addmod.h, Makefile,
Makefile.in
and config.m4.  It is not clear where I add the reference to allow the
linker to know
that unresolved references are in /lib/libm.so or other shared libraries

Any response appreciated.

Mark Diener


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Lame support for win32 mail() function -rant

[md]

Hello Delphi programmer!

Here is a description of the wonderful world of Delphi

--

An exception has occurred at 0x333F248A in Kernel32.DLL.

YOURAPP.EXE has caused a general fault.

Would you like to continue? YES or NO

---

Logical questions to the complement the above win32 problem follow...

---

Is your customer happy that they had to answer this question during
normal business hours? YES or NO

Is your customer happy that they had to answer this question after
normal business hours? YES or NO

Is your customer happy that they had to answer this question on the
weekend? YES or NO

Is your customer happy that they had to answer this question during the
holiday? YES or NO

Does your customer know what a general fault is? YES or NO

Does your customer feel motivated to write you a check to pay for
services rendered 
after receiving a general fault is? YES or NO

Did you tell the customer that it would never happen again? YES or NO

Were you able to capture a stack trace in TD32? YES or NO

Were you able to capture a stack trace on a program that died yesterday?
YES or NO

Is TD32 an ultimately effective Borland debugger? YES or NO

Can TD32 accurately resolve symbol names for Service Pack 3 of Windows
NT.4.0? YES or NO
Can TD32 accurately resolve symbol names for Service Pack 4 of Windows
NT.4.0? YES or NO
Can TD32 accurately resolve symbol names for Service Pack X of Windows
NT.4.0? YES or NO

Does it help to rebuild the VCL with debug information including
system.pas and sysutil.pas? YES or NO

Does it help to rebuild the .ASM components of the VCL with debug
information using TASM? YES OR NO

Do you spend more time writing code than you do fretting about problems
at the customer site? YES or NO

Do you spend more time selling your product than engineering for
different flavors of Win32? YES or NO

Are you happy as a Delphi Programmer after your customer forgot about
you? YES or NO

---

Happy debugging!



[EMAIL PROTECTED] wrote:
> 
> I'm a pascal, delphi programmer so forget about c.
> 
> Problem with the Win32 closed source thing you mentioned is that for this
> particular problem:
> win32/sendmail.c is not really a win32 problem but a php sendmail.c problem.
> 
> A C problem in win32/sendmail.c is not win32 problem.
> 
> So all you "PHP is better than ASP hypsters" get to work!
> lol
> 
> PHP is ok for some problem solving but obviously ASP is better than PHP in
> the long run because of BETTER SUPPORT! :)
> 
> At 01:42 AM 5/22/01 -0400, you wrote:
> >Michael & Joel:
> >
> >Here is a rant for both of you.
> >
> >Joel, Win32 is buggy no matter what flavor and you cannot fix the
> >problem or isolate problems
> >because it is closed source. (I bet poorly written source at that - like
> >MFC garbage)
> >
> >Linux has bugs, but you have the "opportunity" of fixing what you want
> >to. Don't complain about
> >the mail( ) bug, get off your duff and fix it. Or create a simple
> >workaround and keep moving forward.
> >Or hire those supposed win32 developers with your own funds and "do it
> >right" according to your desires.
> >
> >Your mail rant does not even suggest you have tried fixing the bug.  Not
> >everything will be done for you.  But the spirit
> >of the open source community will at least offer ideas and advice on how
> >to go about fixing it.
> >
> >Oops, I'm sorry, Win32 is closed source. Your problems will only get
> >solved by sheer luck. And tons of trial and error.
> >
> >I believe that Win32 worshippers should be responsible for maintaining
> >the port to Win32
> >and that Unix (linux) oriented types should focus on nothing but unix
> >and not waste
> >time considering the portability to Win32. Let the Win32 types create an
> >interface layer back
> >to Win32 if they want PHP4.x badly enough.
> >
> >PHP is suffering time delays due to supporting Win32, it should support
> >unix first, win32 as an after effort by
> >a trailing Win32 team (which will never be able to keep up with true
> >open source pace)
> >
> >Michael, since you hate all the aforementioned OS's, but each seems to
> >have its usefulness in some fashion,
> >what OS do you actually like?
> >
> >End of rant.
> >
> >Mark Diener
> >a battle scarred Win32 soldier...
> >who defected to linux...to allow the wounds to heal...
> >
> >
> >
> >
> >
> >
> >
> >Michael Loftis wrote:
> > >
> > > win32 support is and always has been admittedly lacking.  I personally
> > don't
> > > take it serious as a web serving platform, I have seen any number of sites
> > > hit the wall hard when it comes to scaling with Win32 based
> > platforms.  It's
> > > suitable for testing and development maybe but not deployment.
> > >
> > > PHP has made best-effort to port to a badly screwed up platform.  If
> > you have
> > > a problem with the w

Re: [PHP-DEV] Lame support for win32 mail() function -rant

[md]

Michael & Joel:

Here is a rant for both of you.

Joel, Win32 is buggy no matter what flavor and you cannot fix the
problem or isolate problems
because it is closed source. (I bet poorly written source at that - like
MFC garbage)  

Linux has bugs, but you have the "opportunity" of fixing what you want
to. Don't complain about
the mail( ) bug, get off your duff and fix it. Or create a simple
workaround and keep moving forward.
Or hire those supposed win32 developers with your own funds and "do it
right" according to your desires.

Your mail rant does not even suggest you have tried fixing the bug.  Not
everything will be done for you.  But the spirit
of the open source community will at least offer ideas and advice on how
to go about fixing it.  

Oops, I'm sorry, Win32 is closed source. Your problems will only get
solved by sheer luck. And tons of trial and error.

I believe that Win32 worshippers should be responsible for maintaining
the port to Win32
and that Unix (linux) oriented types should focus on nothing but unix
and not waste
time considering the portability to Win32. Let the Win32 types create an
interface layer back 
to Win32 if they want PHP4.x badly enough.

PHP is suffering time delays due to supporting Win32, it should support
unix first, win32 as an after effort by
a trailing Win32 team (which will never be able to keep up with true
open source pace)

Michael, since you hate all the aforementioned OS's, but each seems to
have its usefulness in some fashion,
what OS do you actually like? 

End of rant.

Mark Diener
a battle scarred Win32 soldier...
who defected to linux...to allow the wounds to heal...







Michael Loftis wrote:
> 
> win32 support is and always has been admittedly lacking.  I personally don't
> take it serious as a web serving platform, I have seen any number of sites
> hit the wall hard when it comes to scaling with Win32 based platforms.  It's
> suitable for testing and development maybe but not deployment.
> 
> PHP has made best-effort to port to a badly screwed up platform.  If you have
> a problem with the win32 port then work on it, submit patches.  Thats how the
> open source model works.
> 
> Sorry that your experience with PHP has been less than ideal.  I'm not an OS
> bigot either, I freely hate Linux, and even BSD, Mac too, and Windows.  I
> believe though that each is right in certain areas.
> 
> [EMAIL PROTECTED] wrote:
> 
> > Well I feel the need for another rant.
> >
> > 
> >
> > I reported several times about the bugs in the win32 mail() function.
> > Over a year ago too.
> >
> > Well it looks like all the response that was given to it was about in the
> > nature of "don't know nothin about it 'cause I'm into linux".
> >
> > If you want to port to Windows you could at least get some win32
> > programmers to do it right.
> >
> > 
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0.4pl1 configure/build questions

[md]

1) 

I have now been adding functions to an extension initiated by ext_skel
for a couple of days
and familiarized myself with the source code layout and build
architecture.

It appears everything is controlled by the ../php4/configure file
which appears to be edited directly by ext_skel when it is run.

Is this correct?

2)

In regard to self-contained extensions, what does PHPIZE do?

3)

The document README.SELF-CONTAINED-EXTENSIONS, it looks like an
"embedded" extension
is one that is in the ../php4/ext/.. subdirectory tree while a
self contained extension is in a directory outside the normal location.  

Is this correct?

OR, is a self contained extension one that requires dlopen(" ") to gain
access to the functions?


4)

If a shared library is added into the PHP.INI file, does that mean it is
loaded on startup
the apache server/libphp4.so and stays loaded.  Meaning that the library
is loaded just one time
instead of being reloaded for each script that calls dlopen(" ") ?


Thanks for any reply,

Mark Diener

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Extending pre-compiled libphp4.so

[md]

Is there a way to take a currently functioning extension
that is being built into a libphp4.so and build it as a shared library
so that I can be sent it to another apache box with a libphp4.so that
has not been
built with integrated extension support (./configure --with-myextension)

I want the PHP function dl("myextension.so) to load the function without
having to compile the extension into libphp4.so.

What looks like the easy way to do this is to modify the Makefile in 
the extension directory to generate a shared library instead of just 
an extension.lo file.

Any ideas or advice?

Mark Diener

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Shared library extensions

[md]

Hello Rasmus:

Thanks for the reply.  I am working with 4.0.4pl1 PHP

I was hoping it would just work, but I cannot get it to work.

Where do I go to get information about config.m4 type files? I have no
idea
how to manage Makefile.in and config.m4 files?  What tools read these
files? (libtool?)
Where is the documentation for these tools?

The README.EXT_SKEL mentions that I have to remove 3 comments from
config.m4 to get it to work.  
What 3 lines do I remove comments from?

This is where my knowledge is weak right now, controlling the input
files.  The actual coding of the module
is the easy part.  

Mark Diener


Rasmus Lerdorf wrote:
> 
> It should just work.  --enable-modname=shared
> and then do a 'make' and you should find your .so in the modules/
> directory.
> 
> -Rasmus
> 
> On Thu, 19 Apr 2001, md wrote:
> 
> > I am getting very close on making a GNU compiled C extension for PHP4
> > using ext_skel.
> >
> >
> > Where does one look to understand what is going on inside the config.m4
> > file (m4 files in general)
> >
> > It is a mystery on how to make a shared library .so file available to
> > PHP4.
> >
> > That is the problem.
> >
> > How to go from a --enable-modname format where the extension in compiled
> > into libphp4.so
> > to a shared library .so file where PHP4 can use the dl("TEST.SO) call to
> > make those functions available.
> >
> > Any help and tips would be appreciated.
> >
> > Mark Diener
> > [EMAIL PROTECTED]
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> 
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Shared library extensions

[md]

I am getting very close on making a GNU compiled C extension for PHP4
using ext_skel.


Where does one look to understand what is going on inside the config.m4
file (m4 files in general)

It is a mystery on how to make a shared library .so file available to
PHP4.

That is the problem. 

How to go from a --enable-modname format where the extension in compiled
into libphp4.so
to a shared library .so file where PHP4 can use the dl("TEST.SO) call to
make those functions available.

Any help and tips would be appreciated.

Mark Diener
[EMAIL PROTECTED]

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]