View Issue Details

IDProjectCategoryView StatusLast Update
0000024XdebugInstallationpublic2003-12-08 00:10
Reporterrich67dev Assigned Torehsack  
PrioritynormalSeveritytrivialReproducibilityunable to reproduce
Status closedResolutionopen 
Summary0000024: is not created on FreeBSD

Everything seems to compile quite nicely, but when I go into the module dir there is no .so

TagsNo tags attached.
Operating SystemFreeBSD
PHP Version4.3.3



2003-10-21 17:49

reporter   ~0000031

Can you please submit the output of 'pkg_info -Lx xdebug' or any error message you receive during 'make build install clean'?


2003-10-23 21:05

reporter   ~0000034

Reminder sent to derick, rich67dev

Could this report please be set to feedback and the submitter please be so kind and provide some more information?

Thanks a lot,


2003-10-24 17:32

reporter   ~0000035

In terms of feedback, I am not entirely sure what more that I can add - I do hate adding useless bugs btw. Basically, when I compile on FreeBSD the main .so package that PHP looks for is not created - there is no barking, no error messages, just no .so (I did a find on the whole system - and its just not there). I would recompile and do it again for you, but there aren't any error messages. I would encourage you to give it a shot yourselves. If it works for you, please send me the procedures you used in temrs of configuration etc - and the state of the packages used.


2003-10-30 11:43

reporter   ~0000038

I asked you especially for the output of 'pkg_info -Lx xdebug'.


2003-11-01 23:00

reporter   ~0000041

Reminder sent to rich67dev

I asked you especially for the output of 'pkg_info -Lx xdebug'.


2003-11-02 00:04

reporter   ~0000042

Sorry about overlooking that,
nope compiled from source using these directions in the readme, noting that
I don't get passed step 6 - no barking -just not created. Also, I could not get pkg_add to work due to dependancies - nonetheless, my system is up to date:

Once you have access to "phpize" and "php-config", do the following:

  1. Unpack the tarball: tar -xzf xdebug-1.x.x.tgz. Note that you do
    not need to unpack the tarball inside the PHP source code tree.
    Xdebug is compiled separately, all by itself, as stated above.

  2. cd xdebug-1.x.x

  3. Run phpize: phpize
    (or /path/to/phpize if phpize is not in your path).

  4. ./configure --enable-xdebug (or: ../configure --enable-xdebug
    --with-php-config=/path/to/php-config if php-config is not in your

  5. Compile the module with "make"

  6. cp modules/ /to/wherever/you/want/it

  7. add the following line to php.ini:

  8. Restart your webserver.

  9. Write a PHP page that calls "phpinfo();" Load it in a browser and
    look for the info on the xdebug module. If you see it, you have been


2003-11-03 16:46

reporter   ~0000043

Please use the port which is available. It takes care, that all will work fine :-)
If you just want the current rc1, I can send you a patch for the port which
will do it.

If you still not want to use the port, just a hint: afaik you must use gmake
instead of bsd's make to build Xdebug.



2003-11-05 01:13

reporter   ~0000044

Last edited: 2003-11-05 01:14

<q>Also, I could not get pkg_add to work due to dependancies</q>

Ehm - you may want to look into sysutils/portupgrade to solve that.

Cannot reproduce this either, with cvs checkout - is built in modules/ as advertised. Make sure your libtool is pointing to the right one. The stock libtool on -STABLE is 1.3.5, which is insufficient - but generates an error during configure.

I used 'BSD make' by the way.

edited on: 2003-11-05 01:14

edited on: 2003-11-05 01:14


2003-11-05 11:07

reporter   ~0000046

cd ${PORTSDIR}/devel/php-xdebug

make install clean

Should work properly. No pkg_add when your playing with more current packages
as the time the package was created. Maybe the old php port exists when the
package was created. Best is ever, use the port, because it uses the source.

The port also handle libtool correctly, etc.



2003-11-12 11:48

reporter   ~0000055

Reminder sent to rich67dev

Please give feedback as requested.


2003-11-12 14:48

reporter   ~0000056

BTW: The system did not send a response to me, but I did just read up. I am assuming that you were not able to compile from source as well?

I am assuming that you are saying that this should work fine:

cd ${PORTSDIR}/devel/php-xdebug

make install clean

without any alterations whatsoever to my system?

I must say that the BSD ports do not work for me 9 times out of 10 - but compiling from source works 10 times out of 10 unless the src is broken. Basically, any messages I get from src compliation in terms of errors should indicate what I might need to do to make something to work. Basically, your src package should have given me some indication as to what I was doing wrong instead of compiling straight through - would you not agree?

So, in reality, the bug is the error messaging, To say that I must use ports is just not a reality for those who really want to control their system and how it builds software. Would you not agree with that thought in theory?


2003-11-13 12:17

reporter   ~0000057

This is a known bug in this bugtracker, you have to come back more often to
see if someone answers your request.

Yes, I want you to use the port, and if you encounter problems, send an e-mail to
the maintainer (me). If you have generic problems with your ports tree, you may
decide to send a general request to

The source package is for systems the author of xdebug is using. For other
systems, you should use the ported version. The FreeBSD system handles auto-tools
and libtool in a different way linux does, so the port is mandatory as long as
you don't know how to manage configuring source packages using auto-tools and
libtool on your own.

If you think, the BSD ports system let you looses the control to your system,
you're wrong. If you know your system, the ports and the port and package tools
are mighty instuments to give you a better control to your system. But this
discussion we should move away to the mailing list, shouldn't


2003-11-13 12:17

reporter   ~0000058

Reminder sent to rich67dev

A bugnote added to your report


2003-12-07 22:22

administrator   ~0000074

Reminder sent to rehsack, rich67dev

What's up with this? Anything I can help to fix, or is it really only related to screwed up buildtools. If that's the case than I'd rather close this report.


2003-12-07 22:23

administrator   ~0000075

Updated severity and category.


2003-12-08 00:10

reporter   ~0000077

Because the submitter didn't respond for a while I rate it as feedback timeout.


2003-12-08 00:10

reporter   ~0000078

feedback timeout

Issue History

Date Modified Username Field Change
2003-10-21 08:45 rich67dev New Issue
2003-10-21 17:49 rehsack Note Added: 0000031
2003-10-23 21:05 rehsack Note Added: 0000034
2003-10-24 10:17 rehsack Status new => assigned
2003-10-24 10:17 rehsack Assigned To => rehsack
2003-10-24 10:22 rehsack Reproducibility always => unable to reproduce
2003-10-24 10:22 rehsack Status assigned => feedback
2003-10-24 17:32 rich67dev Note Added: 0000035
2003-10-30 11:43 rehsack Note Added: 0000038
2003-11-01 23:00 rehsack Note Added: 0000041
2003-11-02 00:04 rich67dev Note Added: 0000042
2003-11-03 16:46 rehsack Note Added: 0000043
2003-11-05 01:13 melvyn Note Added: 0000044
2003-11-05 01:14 melvyn Note Edited: 0000044
2003-11-05 01:14 melvyn Note Edited: 0000044
2003-11-05 11:07 rehsack Note Added: 0000046
2003-11-12 11:48 rehsack Note Added: 0000055
2003-11-12 14:48 rich67dev Note Added: 0000056
2003-11-13 12:17 rehsack Note Added: 0000057
2003-11-13 12:17 rehsack Note Added: 0000058
2003-12-07 22:22 derick Note Added: 0000074
2003-12-07 22:23 derick Note Added: 0000075
2003-12-07 22:23 derick Severity block => trivial
2003-12-07 22:23 derick Category Debug client (console) => Installation
2003-12-08 00:10 rehsack Note Added: 0000077
2003-12-08 00:10 rehsack Status feedback => closed
2003-12-08 00:10 rehsack Note Added: 0000078