Tidy installs Apache and PHP

[ldl@…]

I'm trying to add tidy to an install of PHP 5.2.17 on Snow Leopard 10.6.8 so I can run Drupal. SL ships with PHP 5.3.n

When I run Tidy, it compiles and installs Apache 2.2.19 and PHP 5.3.6.

This is absolutely the last thing I need.

How do I tell Tidy to just compile itself so I can link to it from PHP 5.2.17?

[ldl@…]

Cc Me!

[blb@…]

I take it you mean the php5-tidy port (as opposed to the tidy port which is standalone)? If you need php 5.2.x you want the php52 port, which has variants for many bits including one for tidy:

$ port variants php52
...
   tidy: Add Tidy support

[ldl@…]

That must be it. I figured php5-tidy meant a package of tidy ready for PHP 5.n, not an entire PHP install. I've already compiled PHP 5.2.17 on my own and simply want a few add on modules to round out Drupal 6 development.

What is the stand alone Tidy port that is compatible with php 5.2 that I can port without dragging along a ton of baggage?

[ryandesign (Ryan Carsten Schmidt)]

MacPorts is designed to be self contained. There is no MacPorts port you can install that will compile tidy or anything else for a non-MacPorts PHP.

[ldl@…]

So, compiling all of the PHP 5.3 package broke my existing PHP 5.2.17 install, because MacPorts iconv does not compile correctly for 64 bit and the path goes to opt before local.

So I go to deinstall iconv, but now a bunch of MacPorts ports are dependent upon it and I have to manually uninstall them first, a process that walks all the way back to PHP5-Tidy.

So I laboriously uninstall one at a time until I get down to gss @1.0.1_0, which wants me to unstall map-uw @2007e_0 before it will proceed.

Problem is that I want imap-2007e for PHP 5.2.

So now I can't remove the broken iconv port without throwing out imap-2007.

MacPorts is touted as a simpler system than rolling your own, but it's as screwed up as the jungle of compiling everything myself.

This whole effort has been a regression.

Which is a shame, because I successfully compiled PEG, PNG, FREETYPE and MCRYPT stand alone and integrated them into php 5.2 before Tidy took it upon itself to bombard the OPT directory with files that I don't want which break my configure.

​http://www.malisphoto.com/tips/php-on-os-x.html

[ryandesign (Ryan Carsten Schmidt)]

I apologize that MacPorts has been frustrating for you. It works fine for me and many other users.

What problem are you referring to when you say "iconv does not compile correctly for 64 bit"?

[ldl@…]

All these errors finally went away when I followed the recipe at mailisphotos.

Now they are back.

&& cp libs/libphp5.bundle libs/libphp5.so
ld: warning: dylibs with same install name: /usr/lib/libldap.dylib and /usr/lib/liblber.dylib
ld: warning: dylibs with same install name: /usr/lib/libpthread.dylib and /usr/lib/libm.dylib
ld: warning: dylibs with same install name: /usr/lib/libgssapi_krb5.dylib and /usr/lib/libkrb5.dylib
ld: warning: dylibs with same install name: /usr/lib/libgssapi_krb5.dylib and /usr/lib/libk5crypto.dylib
ld: warning: dylibs with same install name: /usr/lib/libgssapi_krb5.dylib and /usr/lib/libcom_err.dylib
ld: warning: dylibs with same install name: /usr/lib/libpthread.dylib and /usr/lib/libSystem.dylib
Undefined symbols for architecture x86_64:
  "_libiconv_open", referenced from:
      _do_convert in gdkanji.o
      __php_iconv_strlen in iconv.o
      _php_iconv_string in iconv.o
      __php_iconv_strpos in iconv.o
      __php_iconv_mime_decode in iconv.o
      _zif_iconv_substr in iconv.o
      _zif_iconv_mime_encode in iconv.o
      ...
  "_libiconv", referenced from:
      _do_convert in gdkanji.o
      __php_iconv_strlen in iconv.o
      _php_iconv_string in iconv.o
      __php_iconv_strpos in iconv.o
      __php_iconv_appendl in iconv.o
      _zif_iconv_substr in iconv.o
      _zif_iconv_mime_encode in iconv.o
      ...
     (maybe you meant: __libiconv_version)
  "_libiconv_close", referenced from:
      _do_convert in gdkanji.o
      __php_iconv_strlen in iconv.o
      _php_iconv_string in iconv.o
      __php_iconv_strpos in iconv.o
      __php_iconv_mime_decode in iconv.o
      _zif_iconv_substr in iconv.o
      _php_iconv_stream_filter_dtor in iconv.o

[ryandesign (Ryan Carsten Schmidt)]

Could you attach a complete main.log from this failed build? So far it looks like the PHP build has found a libiconv that doesn't have an x86_64 component, which may have been picked up from one of the locations in which you manually installed software (/usr/local/lib would be a likely possibility).

[ldl@…]

/usr/local/lib is the iconv that worked before tidy threw all the extraneous stuff into opt. which is earlier in the PATH.

[ryandesign (Ryan Carsten Schmidt)]

Oh I see. The failed compile is you manually trying to compile php in /usr/local. I'm sorry to have to say it, but we can't support that. Many ports in MacPorts will not work correctly with other software in /usr/local. You're trying to mix and match manually compiled software in /usr/local with MacPorts-installed software. This will not work well. Please pick just one method (either using MacPorts or manually compiling software) and uninstall the other.

[ryandesign (Ryan Carsten Schmidt)]

Or, if you do wish to compile some things manually, and use MacPorts for others, then use a different prefix; /usr/local is a problematic prefix.

[ldl@…]

Well it was all working just fine until the tidy package went berserk. I had jpeg, png, freetype, mcrypt and a few others working.

I am using the llmv-gcc compiler to link it all together.

I am still cleaning up the mess. You really ought to make it clear that PHP and two dozen other packages are going to get installed in the "PHP interface to tidy, the HTML cleaning and repair utility"

It looks like a version of tidy ready to link to PHP, not a whole world unto itself.

[ryandesign (Ryan Carsten Schmidt)]

php5-tidy is an interface to tidy for use by MacPorts php5. All php5-* ports are for use by MacPorts php5, not any other PHP.

You can use "port rdeps" to see what all a port will install, for example:

$ port rdeps php5-tidy
The following ports are dependencies of php5-tidy @5.3.6_0:
  php5
    pkgconfig
      glib2
        autoconf
          perl5
            perl5.12
          m4
          help2man
            p5-locale-gettext
              gettext
                libiconv
                  gperf
                ncurses
                  ncursesw
                expat
        automake
        libtool
        zlib
    autoconf213
      gawk
    gsed
    libxml2
    bzip2
    mhash
    pcre
      readline
    apache2
      apr
      apr-util
        db46
        sqlite3
      openssl
  tidy

[ldl@…]

Too late now.

[ldl@…]

You may know what you think PHP5-Tidy does, but the web site description does not make that clear.

It's too easy for a user to make a fatal mistake.

Either take some constructive feedback or blame the stupid user.

Your choice.

[ryandesign (Ryan Carsten Schmidt)]

I again apologize that MacPorts has been frustrating for you. But it behaves as we intend it to. If you require further assistance using MacPorts please discuss on the macports-users mailing list.

[ldl@…]

It may behave the way you intend it to, but it does not behave the way the users expect it to behave by reading your website.

Think about that distinction for a minute.

If you don't intend to change the way it behaves, change the website.

I was within a package or two of a goal until your fancy tool behaved the way you intended -- and I did not reasonably expect.

You have no idea how frustrating that is after the effort I have already go to to sort out PHP 5.2.7, MySQL 5.5, Apache 2.the latest on 10.6.9 compiled with llvm-gcc just so I can continue to develop in Drupal 6 which is not fully ready for PHP 5.3 yet.

It's your way or the highway, despite the fact I had your modules running with my compile.

[ryandesign (Ryan Carsten Schmidt)]

What specifically would you like us to change?

When you refer to the web site, I assume you mean ​http://www.macports.org/ports.php?by=name&substr=php5-tidy

On that page it shows the port description ("a PHP interface to tidy, the HTML cleaning and repair utility") and lists its dependencies ("php5 tidy") -- this means that as prerequisites it will install the ports php5 and tidy.

I agree the web site could be improved in many ways. But nobody has so far taken on this task. And the web site is not the primary means by which we expect users to discover about ports; users are expected to use the "port" command on the command line; commands like "port search", "port info", "port variants", "port deps", etc. provide more information than the web site does. The macports-users mailing list is a good place to ask any questions you may have about how to use MacPorts best.

It seems your expectation is that MacPorts-installed software will integrate nicely with other software you have already installed outside of MacPorts. MacPorts is specifically designed not to do that, as explained in FAQ, so that's not going to change.

[ldl@…]

No. I expect the website will make it clear, in plain English, what a module is and what is going to installed.

You are so used to the system you assume everyone else is, too.

NOTE: This package will do a full install of PHP 5.3.6 in /opt/local, along with (a couple of dozen ports you don't expect). If you are looking to just port the Tidy lib go <link> here </link>

Something like that would do nicely.

If you expect the users to use 'port info' tell them to do so on the page, for example.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ldl@…:

No. I expect the website will make it clear, in plain English, what a module is and what is going to installed.

You are so used to the system you assume everyone else is, too.

That's absolutely true, and it's often hard for us to know how it is for users less familiar with the system, so thank you for sharing your perspective on this. I agree we should do something about it.

NOTE: This package will do a full install of PHP 5.3.6 in /opt/local, along with (a couple of dozen ports you don't expect). If you are looking to just port the Tidy lib go <link> here </link>

The problem is that we don't have any per-port web pages at all yet. We only have a fairly poor search results page with some rudimentary information taken from the portfile. We definitely want per-port pages; that's #19300. Once somebody actually tackles the problem of creating a per-port page system, there's a whole host of useful information we could display on them. For example I agree that some ports have a very large number of dependencies, and that this is not necessarily expected and so it would be good to display in some way, either by showing a graph of all the dependencies, and/or by just showing how many there are. Of course dependencies can vary by variant. In any case, since we have over 12,000 ports, it's going to be something automatically generated.