Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31719
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daleenterprise.com from 67.78.11.229 cause and error)
In-Reply-To: <cd5680a20708160708i283435e0v12e7ae6946abd2b0@mail.gmail.com>
References: <153371E8-FE64-4C88-B3F9-2A3F0EF4D052@daleenterprise.com> <cd5680a20708160708i283435e0v12e7ae6946abd2b0@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <576213A3-77F8-47DA-BCDD-07527A5AD11E@daleenterprise.com>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Sat, 18 Aug 2007 14:37:47 -0400
To: Alexey Zakhlestin <indeyets@gmail.com>
MTA-Interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.1.0 at daleenterprise.com
Subject: Re: [PHP-DEV] Issues with custom extension. [found cause - possible build bug]
From: buildsmart@daleenterprise.com (BuildSmart)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 16, 2007, at 10:08:12, Alexey Zakhlestin wrote:

> 1) did you try to hook into your extension with debugger?
> 2) is your extension open-source (I mean: can you show the actual  
> source-code?)
> 3) do you develop your extension with both zts and debug modes  
> enabled?

Digging a little further into the issue which I thought was just  
related to my module (it appears that all of the shared extensions  
don't work as expected either), I came up with the following.

After examining the build/link phases it appears that it doesn't seem  
to like the allow_undefined_tag if you build using gcc 3.3 or gcc 3.5  
or you build for more than one cpu architecture.

I tried adding the '-flat_namespace' to the CFLAGS as a possible  
solution however it complains that you cannot specify '- 
flat_namespace' and '-twolevel_namespace' at the same time which is  
understandable

I edited the Makefile and removed the '--silent' directives so I  
could see the actual build take place and for some reason it appears  
to default to using the non-pic items even for the shared extensions  
but if you force the creation of just the shared extension with the '- 
dynamic' flag it then utilizes the pic objects which is strange  
because you would think that the '-prefer-pic' would force the use of  
the pic objects if they are available.

Since Apple has crossed over the platform bridge with it's intel line  
of hardware, building in multiple architecture is going to become a  
normal way of life so perhaps a more dynamic solution might be in order.

I substantiated my findings with the following edits (in two places)  
to the configure file: (this was a temporary workaround pending a  
proper solution by the dev-team)

     darwin* | rhapsody*)
       case $host_os in
         rhapsody* | darwin1.[012])
          allow_undefined_flag='${wl}-undefined ${wl}suppress'
          ;;
        *) # Darwin 1.3 on
          if test -z ${MACOSX_DEPLOYMENT_TARGET} ; then
            allow_undefined_flag='${wl}-flat_namespace ${wl}- 
undefined ${wl}suppress'
          else
            case ${MACOSX_DEPLOYMENT_TARGET} in
              10.[012])
                allow_undefined_flag='${wl}-flat_namespace ${wl}- 
undefined ${wl}suppress'
                ;;
              10.*)
                 # allow_undefined_flag, $1)='${wl}-undefined ${wl} 
dynamic_lookup'
                 allow_undefined_flag='${wl}-flat_namespace ${wl}- 
undefined ${wl}suppress'
                ;;
            esac
          fi
          ;;
       esac

Now that I've isolated the build issue, can this be resolved without  
requiring manual edits to the configure script?

Perhaps a test of the active gcc version?

Testing the CFLAGS/CPPFLAGS/LDFLAGS for '-arch' might be a bit  
problematic since they are sometimes provided before the configure  
command, sometimes as part of the environment.



As well, to avoid wasting build time on static libs that aren't used  
in Mac OS X, I made an additional change to the configure script:  
(not really required)

     if test "$GCC" = yes ; then
     	output_verbose_link_cmd='echo'
         archive_cmds='$CC -dynamiclib $allow_undefined_flag -o $lib  
$libobjs $deplibs $compiler_flags -install_name $rpath/$soname  
$verstring'
       #module_cmds='$CC $allow_undefined_flag -o $lib -bundle  
$libobjs $deplibs$compiler_flags'
       module_cmds='$CC $allow_undefined_flag -o $lib -dynamic - 
bundle $libobjs $deplibs$compiler_flags'

All this does is prevent the static modules from being built (no  
name.a files, only name.so files).

>
> On 8/16/07, BuildSmart <buildsmart@daleenterprise.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I wrote an extension/module (quite some time ago) for PHP4, for the
>> last year or so (on and off) I've been rewriting it for PHP5.
>>
>> Under PHP4 it works properly as an embedded extension or a loadable
>> module.
>>
>> Under PHP5 it only appears to work properly as an embedded extension
>> but when it's a loadable module it fails to work properly.
>>
>> What I mean by 'fails to work' properly is that it doesn't perform
>> the tasks it's supposed to perform.
>>
>> I realize that this is not very explanatory and I really don't know
>> how else to explain it.
>>
>> Since I don't know what the problem is or where to begin I was hoping
>> I could find some kind soul with a little time could assist me in
>> resolving this problem.
>>
>> - -- Dale
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2.2 (Darwin)
>>
>> iD8DBQFGxFMp0hzWbkf0eKgRAoEsAKCn0XM4NEuo2vZQUciZEZ/t8KfCfwCfb4jE
>> hCttSqcjFpXG/oYB4V+t8oY=
>> =2XmB
>> -----END PGP SIGNATURE-----
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> -- 
> Alexey Zakhlestin
> http://blog.milkfarmsoft.com/

- -- Dale


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFGxzx70hzWbkf0eKgRAr0qAJ4pHdbQRp+xx4zoLS1eyZtUIxEDyACfcWMy
bvT0nONFhUKCSsXMMTfgG8s=
=Y1ue
-----END PGP SIGNATURE-----