Abuse Department
2010-11-05 10:33:47 UTC
Response
---------------------------------------------------------------
********** This is an automated reply to your message to Email Abuse. **********
Your message has been delivered to our email abuse department. This department handles complaints from users that are receiving unwanted email. We try our best to investigate all reports of abuse. If we determine that the email you reported was in fact sent from an email address at one of our domains, or by way of computers operated by us, we will take the appropriate action.
If you did not include the original "message headers" along with your message, please do so by replying to this message, leaving the subject line intact (which contains our tracking identification), and including all email headers. Email headers show specific details regarding the source provider, path, originating program, and destination of the message which is not shown within the TO: and FROM: address fields of the email.
Unfortunately, "spammers" use a variety of techniques to mask an email's actual point of origin, such as by forging information to make it appear as though the email originated from a domain that is well recognized across the Internet. Accordingly, the information in the header is very helpful in assisting us in our investigation.
We regret any inconvenience this may have caused and appreciate you bringing this matter to our attention.
Regards,
The Email Abuse Department
Discussion Thread
---------------------------------------------------------------
Customer ( php) - 11/05/2010 06:33 AM
[ Christine Ross ]
you use when starting Apache, making sure you have no LD_* variables
set in your env. Does it still come up with the "libcurl/7.19.5"-path?
RUN_PATH the binary is built with. You can override this using things
like LD_LIBRARY_PATH in your shell environment, but it doesn't change
the RUN_PATH in the binary.
CFLAGS='-L/usr/local/curl-7.19.5/lib -R/usr/local/curl-7.19.5/lib'; export CFLAGS
I've used it with success before on both Solaris8 and 10 (sparc,
SunCC) to get a proper RUN_PATH in the binary.
Failing all else, you might try use a nifty little tool called
'chrpath' to brute-force a new RPATH in your binary:
http://linux.die.net/man/1/chrpath
Caveat: I've only used it on linux x86; don't know if it'll work on SPARC.
~ksvee
---------------------------------------------------------------
********** This is an automated reply to your message to Email Abuse. **********
Your message has been delivered to our email abuse department. This department handles complaints from users that are receiving unwanted email. We try our best to investigate all reports of abuse. If we determine that the email you reported was in fact sent from an email address at one of our domains, or by way of computers operated by us, we will take the appropriate action.
If you did not include the original "message headers" along with your message, please do so by replying to this message, leaving the subject line intact (which contains our tracking identification), and including all email headers. Email headers show specific details regarding the source provider, path, originating program, and destination of the message which is not shown within the TO: and FROM: address fields of the email.
Unfortunately, "spammers" use a variety of techniques to mask an email's actual point of origin, such as by forging information to make it appear as though the email originated from a domain that is well recognized across the Internet. Accordingly, the information in the header is very helpful in assisting us in our investigation.
We regret any inconvenience this may have caused and appreciate you bringing this matter to our attention.
Regards,
The Email Abuse Department
Discussion Thread
---------------------------------------------------------------
Customer ( php) - 11/05/2010 06:33 AM
[ Christine Ross ]
My server is Solaris 10 Sparc and Im using Suns cc compilers.
I have curl compiled into /usr/local/lib and compiled again native
Solaris 10 openssl. I installed another version into
/usr/local/curl-7.19.5 and compiled against a different openssl.
Then I compiled php using that later curl verion (see below). Today
I did an ldd against php shows it is using /usr/local/lib. I dont
believe I specify the lib directory on the php --with-curl line.
Doesnt my LD_RUN_PATH specify where to find the library files? Both
versions are 7.19.5 but I need one compiled against the native
libraries.
What is even stranger is that if I run php i it will show php
compiled against the 2^nd curl installation (libcurl/7.19.5
OpenSSL/0.9.8h zlib/1.2.3) but phpinfo on a web browser shows the
curl info from /usr/local/lib (libcurl/7.19.5 OpenSSL/0.9.7d
zlib/1.2.3).
Do an 'ldd' on the PHP binary using the same (clean) shell environmentI have curl compiled into /usr/local/lib and compiled again native
Solaris 10 openssl. I installed another version into
/usr/local/curl-7.19.5 and compiled against a different openssl.
Then I compiled php using that later curl verion (see below). Today
I did an ldd against php shows it is using /usr/local/lib. I dont
believe I specify the lib directory on the php --with-curl line.
Doesnt my LD_RUN_PATH specify where to find the library files? Both
versions are 7.19.5 but I need one compiled against the native
libraries.
What is even stranger is that if I run php i it will show php
compiled against the 2^nd curl installation (libcurl/7.19.5
OpenSSL/0.9.8h zlib/1.2.3) but phpinfo on a web browser shows the
curl info from /usr/local/lib (libcurl/7.19.5 OpenSSL/0.9.7d
zlib/1.2.3).
you use when starting Apache, making sure you have no LD_* variables
set in your env. Does it still come up with the "libcurl/7.19.5"-path?
Why isnt php compiling against the correct curl?
Thanks for any help.
# ldd /usr/local/bin/php | grep curl
libcurl.so.4 => /usr/local/lib/libcurl.so.4
#
This tells you which library the binary has linked to, i.e. whichThanks for any help.
# ldd /usr/local/bin/php | grep curl
libcurl.so.4 => /usr/local/lib/libcurl.so.4
#
RUN_PATH the binary is built with. You can override this using things
like LD_LIBRARY_PATH in your shell environment, but it doesn't change
the RUN_PATH in the binary.
# more ConfigurePHP
#!/bin/sh
PATH=/opt/SUNWspro/bin:/usr/local/bin:/usr/bin:/usr/ccs/bin:/usr/sfw/bin:/usr/dt/bin:/usr/openwin/
bin:/usr/sbin; export PATH
LD_RUN_PATH=/usr/local/curl-7.19.5/lib:/usr/sfw/lib:/usr/local/lib; export LD_RUN_PATH
Try adding CFLAGS including your curl to your build, e.g.#!/bin/sh
PATH=/opt/SUNWspro/bin:/usr/local/bin:/usr/bin:/usr/ccs/bin:/usr/sfw/bin:/usr/dt/bin:/usr/openwin/
bin:/usr/sbin; export PATH
LD_RUN_PATH=/usr/local/curl-7.19.5/lib:/usr/sfw/lib:/usr/local/lib; export LD_RUN_PATH
CFLAGS='-L/usr/local/curl-7.19.5/lib -R/usr/local/curl-7.19.5/lib'; export CFLAGS
I've used it with success before on both Solaris8 and 10 (sparc,
SunCC) to get a proper RUN_PATH in the binary.
Failing all else, you might try use a nifty little tool called
'chrpath' to brute-force a new RPATH in your binary:
http://linux.die.net/man/1/chrpath
Caveat: I've only used it on linux x86; don't know if it'll work on SPARC.
~ksvee