markcox/libproxy

Automatically exported from code.google.com/p/libproxy

libproxy's Issues

when evaluating ignore rules, domain names aren't converted to IP addresses

What steps will reproduce the problem?
1. Invoke gnome-network-preferences
2. Select [Proxy Configuration] tab and set [HTTP proxy] in [Manual proxy
configuration].
e.g. http://proxy:8080
3. Select [Ignored Hosts] and put my network address in [Ignore Host List].
e.g. 129.158.0.0/16
4. Invoke /usr/demo/jds/bin/proxy
5. Type my local host in stdout.
e.g http://foo

What is the expected output? What do you see instead?
expected: direct://
actually: the proxy set in GConf

What version of the product are you using? On what operating system?
0.2.3

Please provide any additional information below.
libproxy does not have the feature to convert url to ip address

Original issue reported on code.google.com by [email protected] on 16 Feb 2009 at 2:27

spelling errors

/trunk/src/bin/proxy.c
76  * Prints an array of proxie. Proxies are space separated.

proxie => proxies

131         /* Destantiate the proxy factory object */

Destantiate (not a word) => Destroy / Dispose of ?

/trunk/src/bindings/python/libproxy.py
javascript => JavaScript

80         to read the configuration (i.e. from gconf, kconfig, etc).  

=> to read the configuration (e.g. from GConf and KConfig).

What steps will reproduce the problem?
1. read the sources.

Original issue reported on code.google.com by [email protected] on 6 Nov 2008 at 9:15

warning message issued in normal condition confuses users.

What steps will reproduce the problem?
1. connect to the internet without using any proxy
2. this message is issued:
 *** Unable to locate PAC! Falling back to direct...
3. It *looks* like a warning message.
see other original comments:
https://bugzilla.redhat.com/show_bug.cgi?id=490345#c6

What is the expected output? What do you see instead?
no message should be issued since the operation are normal.
Or at least, something that tell which component is involved.

What version of the product are you using? On what operating system?
libproxy-0.2.3 (Linux)

Please provide any additional information below.
This problem was initially reported in:
As reported in https://bugzilla.redhat.com/show_bug.cgi?id=490345

Original issue reported on code.google.com by [email protected] on 16 Mar 2009 at 10:52

Add gnome-settings-daemon to the list of X clients to check

With a lightweight gnome environment, without gnome-panel or even
gnome-session but still using all the gnome infrastructure, the gnome
plugin does not detect it has to be run.

Adding gnome-settings-daemon solve the issue in our specific case and is
probably better choice than gnome-panel as it's lower in the stack.

Patch attached.

Original issue reported on code.google.com by [email protected] on 16 Mar 2009 at 3:13

Attachments:

• libproxy-fix-gnome-detection.patch

warning in proxy.h

when compiling a libproxy-using app with gcc -Wstrict-prototypes:

    /opt/foo/include/proxy.h:30: warning: function declaration isn’t a
prototype

because of:

    pxProxyFactory *px_proxy_factory_new();

It should be

    pxProxyFactory *px_proxy_factory_new(void);

Original issue reported on code.google.com by [email protected] on 6 Oct 2008 at 4:25

Implicit declaration of function ‘strdup’

I'm attaching the patch which fixes this problem:

proxy.c:50: warning: implicit declaration of function ‘strdup’

Original issue reported on code.google.com by [email protected] on 15 May 2009 at 11:06

Attachments:

• libproxy-0.2.3-fix-implicit-declaration.patch

[PATCH]libproxy 0.2.3 fail to compile with mozjs support

What steps will reproduce the problem?
1. ./configure --with-mozjs
2. make

What is the expected output? What do you see instead?

mozjs.c:32:19: error: jsapi.h: No such file or directory
mozjs.c:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'dnsResolve'
mozjs.c:70: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'myIpAddress'
mozjs.c:83: error: expected specifier-qualifier-list before 'JSRuntime'
mozjs.c: In function 'ctxs_free':
mozjs.c:92: error: 'ctxStore' has no member named 'ctx'
mozjs.c:92: warning: implicit declaration of function 'JS_DestroyContext'
mozjs.c:92: error: 'ctxStore' has no member named 'ctx'
mozjs.c:93: error: 'ctxStore' has no member named 'run'
mozjs.c:93: warning: implicit declaration of function 'JS_DestroyRuntime'
mozjs.c:93: error: 'ctxStore' has no member named 'run'
mozjs.c:94: error: 'ctxStore' has no member named 'cls'
mozjs.c:94: error: 'ctxStore' has no member named 'cls'
mozjs.c:95: error: 'ctxStore' has no member named 'pac'
mozjs.c: In function 'ctxs_new':
mozjs.c:101: error: 'JSObject' undeclared (first use in this function)
mozjs.c:101: error: (Each undeclared identifier is reported only once
mozjs.c:101: error: for each function it appears in.)
mozjs.c:101: error: 'global' undeclared (first use in this function)
mozjs.c:102: error: 'jsval' undeclared (first use in this function)
mozjs.c:102: error: expected ';' before 'rval'
mozjs.c:108: error: 'ctxStore' has no member named 'cls'
mozjs.c:108: error: 'JSClass' undeclared (first use in this function)
mozjs.c:109: error: 'ctxStore' has no member named 'cls'
mozjs.c:110: error: 'ctxStore' has no member named 'cls'
mozjs.c:111: error: 'ctxStore' has no member named 'cls'
mozjs.c:111: error: 'JS_PropertyStub' undeclared (first use in this function)
mozjs.c:112: error: 'ctxStore' has no member named 'cls'
mozjs.c:113: error: 'ctxStore' has no member named 'cls'
mozjs.c:114: error: 'ctxStore' has no member named 'cls'
mozjs.c:115: error: 'ctxStore' has no member named 'cls'
mozjs.c:115: error: 'JS_EnumerateStub' undeclared (first use in this function)
mozjs.c:116: error: 'ctxStore' has no member named 'cls'
mozjs.c:116: error: 'JS_ResolveStub' undeclared (first use in this function)
mozjs.c:117: error: 'ctxStore' has no member named 'cls'
mozjs.c:117: error: 'JS_ConvertStub' undeclared (first use in this function)
mozjs.c:118: error: 'ctxStore' has no member named 'cls'
mozjs.c:118: error: 'JS_FinalizeStub' undeclared (first use in this function)
mozjs.c:121: error: 'ctxStore' has no member named 'run'
mozjs.c:121: warning: implicit declaration of function 'JS_NewRuntime'
mozjs.c:122: error: 'ctxStore' has no member named 'ctx'
mozjs.c:122: warning: implicit declaration of function 'JS_NewContext'
mozjs.c:122: error: 'ctxStore' has no member named 'run'
mozjs.c:123: warning: implicit declaration of function 'JS_NewObject'
mozjs.c:123: error: 'ctxStore' has no member named 'ctx'
mozjs.c:123: error: 'ctxStore' has no member named 'cls'
mozjs.c:124: warning: implicit declaration of function 'JS_InitStandardClasses'
mozjs.c:124: error: 'ctxStore' has no member named 'ctx'
mozjs.c:127: warning: implicit declaration of function 'JS_DefineFunction'
mozjs.c:127: error: 'ctxStore' has no member named 'ctx'
mozjs.c:127: error: 'dnsResolve' undeclared (first use in this function)
mozjs.c:128: error: 'ctxStore' has no member named 'ctx'
mozjs.c:128: error: 'myIpAddress' undeclared (first use in this function)
mozjs.c:129: warning: implicit declaration of function 'JS_EvaluateScript'
mozjs.c:129: error: 'ctxStore' has no member named 'ctx'
mozjs.c:130: error: 'rval' undeclared (first use in this function)
mozjs.c:133: error: 'ctxStore' has no member named 'ctx'
mozjs.c:139: error: 'ctxStore' has no member named 'pac'
mozjs.c: In function 'mozjs_pacrunner':
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:158: error: 'ctxStore' has no member named 'pac'
mozjs.c:176: error: 'jsval' undeclared (first use in this function)
mozjs.c:176: error: expected ';' before 'args'
mozjs.c:182: error: expected ';' before 'rval'
mozjs.c:183: error: 'JSBool' undeclared (first use in this function)
mozjs.c:183: error: expected ';' before 'result'
mozjs.c:184: error: 'result' undeclared (first use in this function)
mozjs.c:185: warning: implicit declaration of function 'JS_GetStringBytes'
mozjs.c:185: warning: implicit declaration of function 'JS_ValueToString'
mozjs.c:185: error: 'ctxStore' has no member named 'ctx'
mozjs.c:185: error: 'rval' undeclared (first use in this function)
mozjs.c:185: warning: passing argument 1 of 'px_strdup' makes pointer from
integer without a cast
make[3]: *** [mozjs_la-mozjs.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: compile:  i686-pc-linux-gnu-gcc -DPACKAGE_NAME=\"libproxy\"
-DPACKAGE_TARNAME=\"libproxy\" -DPACKAGE_VERSION=\"0.2.3\"
"-DPACKAGE_STRING=\"libproxy 0.2.3\""
-DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"libproxy\"
-DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 -DHAVE__BOOL=1
-DHAVE_STDBOOL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I. -I../../src/lib -g
-std=c99 -O3 -march=core2 -mssse3 -msse4.1 -mcx16 -fomit-frame-pointer
-pipe -mfpmath=sse -DPLUGINDIR=\"/usr/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/etc\" -D_POSIX_C_SOURCE=1 -MT file_la-file.lo -MD -MP -MF
.deps/file_la-file.Tpo -c file.c  -fPIC -DPIC -o .libs/file_la-file.o
mv -f .deps/file_la-file.Tpo .deps/file_la-file.Plo
libtool: link: i686-pc-linux-gnu-gcc -shared  .libs/envvar_la-envvar.o  
-Wl,-rpath
-Wl,/var/tmp/portage/net-libs/libproxy-0.2.3/work/libproxy-0.2.3/src/lib/.libs
../lib/.libs/libproxy.so -lm -ldl  -march=core2 -mssse3 -msse4.1 -mcx16
-mfpmath=sse -Wl,--as-needed   -Wl,-soname -Wl,envvar.so -o .libs/envvar.so
libtool: link: ( cd ".libs" && rm -f "envvar.la" && ln -s "../envvar.la"
"envvar.la" )
make[3]: Leaving directory
`/var/tmp/portage/net-libs/libproxy-0.2.3/work/libproxy-0.2.3/src/plugins'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/var/tmp/portage/net-libs/libproxy-0.2.3/work/libproxy-0.2.3/src/plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/net-libs/libproxy-0.2.3/work/libproxy-0.2.3/src'
make: *** [all-recursive] Error 1



What version of the product are you using? On what operating system?
0.2.3 release on GNU/Linux gentoo 

Please provide any additional information below.

architecture host is amd64, CFLAGS make.conf profile are
: -march=native -msse3 -O2 -pipe (stable)

Original issue reported on code.google.com by [email protected] on 12 Apr 2009 at 5:53

Attachments:

• libproxy-0.2.3-fix-libxul-cflags.patch

file:// urls for PAC location

Currently, only http:// urls are considered valid locations to find a PAC
file. This should be extended with file:// locations.

Original issue reported on code.google.com by [email protected] on 27 Feb 2009 at 11:10

PX_CONFIG_ORDER no longer honored

We used to have the option to pass PX_CONFIG_ORDER in order to 'favor' a
specific config source. 

This option is missing now and it seems impossible to control where from
the configuration comes.

This breaks for example the entire test suite.

Original issue reported on code.google.com by [email protected] on 22 May 2009 at 3:57

libproxy does not build with LDFLAGS="-Wl,--as-needed"

$ LDFLAGS="-Wl,--as-needed" make
<snip>
Making all in bin
make[2]: Entering directory `/home/nirbheek/projects/libproxy-0.2.3/src/bin'
/bin/sh ../../libtool --tag=CC   --mode=link gcc -I../../src/lib -g
-std=c99 -g -O2 -DPLUGINDIR=\"/usr/local/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/local/etc\" -D_POSIX_C_SOURCE=1 -ldl -Wl,--as-needed -o
proxy proxy-proxy.o ../lib/libproxy.la 
libtool: link: gcc -I../../src/lib -g -std=c99 -g -O2
-DPLUGINDIR=\"/usr/local/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/local/etc\" -D_POSIX_C_SOURCE=1 -Wl,--as-needed -o
.libs/proxy proxy-proxy.o  -ldl ../lib/.libs/libproxy.so -lm
../lib/.libs/libproxy.so: undefined reference to `dlsym'
../lib/.libs/libproxy.so: undefined reference to `dlerror'
../lib/.libs/libproxy.so: undefined reference to `dlopen'
../lib/.libs/libproxy.so: undefined reference to `dlclose'
collect2: ld returned 1 exit status
<snip>

This is due to a missing -ldl in libproxy_la_LDFLAGS in
src/lib/Makefile.am. Attached is a patch to fix that.

Original issue reported on code.google.com by [email protected] on 30 Jan 2009 at 9:35

Attachments:

• libproxy-0.2.3-fix-as-needed-problem.patch

WebKit/GTK+ integration tracking bug

We're interested in using libcurl in the GTK+ WebKit port's curl HTTP
backend (the default).

This would probably be done with GModule/dlopen to avoid a hard dependency
(libproxy isn't widely packaged yet), but moreover to avoid the circular
dependency for distributions building libproxy and webkit-1.0 since
libproxy depends on webkit-1.0 (which is a good thing).

There are a few questions though:

1) We want to avoid libproxy loading mozjs if at all possible since our
JavaScriptCore implementation will already be loaded into memory and
initialised. Is there some way we can tell libproxy to favour our JS backend?

2) Performance/latency. proxy.h exposes a very small API and the
documentation doesn't really explain the performance characteristics of
px_proxy_factory_get_proxies(). Is it a non-blocking call in all situations
or is the caller expected to run it in a thread? Does it cache results
sensibly? Are we expected to call this function for every single HTTP
request we make during a load? These questions are important when
considering that our browser engine is judged by its performance and
UI/network latency.

3) Our current HTTP backend is libcurl. Is there reference code for
integrating libproxy with libcurl? From a brief look at the two APIs, this
is more involved than simply passing the string results from libproxy to
CURLOPT_PROXY and if we want to get it right for all possible proxy types
we'll benefit from someone with expertise in libproxy/libcurl.

Original issue reported on code.google.com by [email protected] on 14 Sep 2008 at 4:19

Add option for Seamonkey

What steps will reproduce the problem?
Build from source on Slackware

What is the expected output?
no mozjs by default

What version of the product are you using? On what operating system?
Seamonkey 1.1.15, Slackware 12.2

Please provide any additional information below.
I use Slackware and it comes with the Seamonkey development environment.  I
built libproxy from source but without any modifications and I couldn't get
the mozjs option to work.  I actually patched the configure script with
"sed -i 's|mozilla-js|seamonkey-js|g' configure" to get mozjs support.  I
would appreciate it if seamonkey-js was an option for mozjs support.

Original issue reported on code.google.com by [email protected] on 1 Apr 2009 at 3:36

Missing netinet/in.h includes causing failures on BSD

I've just checked out trunk; most of these have been fixed for issue #37
but some files are still using sockaddr_in* without including netinet/in.h

Attached patch fixes this.

Original issue reported on code.google.com by [email protected] on 12 May 2009 at 12:20

Attachments:

• in.patch

'proxy' command hangs forever when trying to test it out.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Original issue reported on code.google.com by jeffschroed on 9 Jan 2008 at 12:59

Can't build libprxy-0.2.3 due to mozjs.c:32:19: error: jsapi.h: No such file or directory

What steps will reproduce the problem?
1. jhbuild liibproxy
2. see it ./configure --prefix /opt/gnome2 --libdir ${exec_prefix}/lib64
--without-networkmanager --disable-static --disable-scrollkeeper
--disable-gtk-doc
3. see it FAILing

What is the expected output? What do you see instead?
I expected it to compile fine, especially *after* the configure has passed!

What version of the product are you using? On what operating system?
Ubuntu 8.10 gut that shouldn't matter, as the configure has already passed
and should have checked for dependencies!

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 25 Feb 2009 at 3:37

compile fails

What steps will reproduce the problem?
1. configure and compile


What is the expected output? What do you see instead?
compilation failure

What version of the product are you using? On what operating system?
ubuntu/x86_64 8.10

gcc-Version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)


    Plugins to build...
        envvar          : yes
        file            : yes
        gnome           : yes
        kde             : yes
        webkit          : no
        mozjs           : yes
        networkmanager  : no

    Bindings to build...
        python          : yes
        java            : no
        dotnet          : no
------------------------------------------------------


 gcc -DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\" -
DPACKAGE_VERSION=\"0.2.3\" "-DPACKAGE_STRING=\"libproxy 0.2.3\"" -
DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"libproxy\" -
DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -
DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -
DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -
DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -
DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I. -I../../src/lib -DXP_UNIX -
DJS_THREADSAFE -I/opt/gnome2/include/nspr -I/usr/include/xulrunner-1.9.0.4/
stable -g -std=c99 -g -O1 -Wall -march=athlon64 -DPLUGINDIR=\"/opt/gnome2/
lib64/libproxy/0.2.3/plugins\" -DSYSCONFDIR=\"/opt/gnome2/etc\" -
D_POSIX_C_SOURCE=1 -MT mozjs_la-mozjs.lo -MD -MP -MF .deps/mozjs_la-
mozjs.Tpo -c mozjs.c  -fPIC -DPIC -o .libs/mozjs_la-mozjs.o
mozjs.c:32:19: error: jsapi.h: No such file or directory
mozjs.c:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'dnsResolve'
mozjs.c:70: error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'myIpAddress'
mozjs.c:83: error: expected specifier-qualifier-list before 'JSRuntime'
mozjs.c: In function 'ctxs_free':
mozjs.c:92: error: 'ctxStore' has no member named 'ctx'
mozjs.c:92: warning: implicit declaration of function 'JS_DestroyContext'
mozjs.c:92: error: 'ctxStore' has no member named 'ctx'
mozjs.c:93: error: 'ctxStore' has no member named 'run'
mozjs.c:93: warning: implicit declaration of function 'JS_DestroyRuntime'
mozjs.c:93: error: 'ctxStore' has no member named 'run'
mozjs.c:94: error: 'ctxStore' has no member named 'cls'
mozjs.c:94: error: 'ctxStore' has no member named 'cls'
mozjs.c:95: error: 'ctxStore' has no member named 'pac'
mozjs.c: In function 'ctxs_new':
mozjs.c:101: error: 'JSObject' undeclared (first use in this function)
mozjs.c:101: error: (Each undeclared identifier is reported only once
mozjs.c:101: error: for each function it appears in.)
mozjs.c:101: error: 'global' undeclared (first use in this function)
mozjs.c:102: error: 'jsval' undeclared (first use in this function)
mozjs.c:102: error: expected ';' before 'rval'
mozjs.c:108: error: 'ctxStore' has no member named 'cls'
mozjs.c:108: error: 'JSClass' undeclared (first use in this function)
mozjs.c:109: error: 'ctxStore' has no member named 'cls'
mozjs.c:110: error: 'ctxStore' has no member named 'cls'
mozjs.c:111: error: 'ctxStore' has no member named 'cls'
mozjs.c:111: error: 'JS_PropertyStub' undeclared (first use in this 
function)
mozjs.c:112: error: 'ctxStore' has no member named 'cls'
mozjs.c:113: error: 'ctxStore' has no member named 'cls'
mozjs.c:114: error: 'ctxStore' has no member named 'cls'
mozjs.c:115: error: 'ctxStore' has no member named 'cls'
...

Original issue reported on code.google.com by [email protected] on 12 Dec 2008 at 12:13

PAC implementation does not return correct values

the PAC implementation seems to be 'strange'.

I have a proxy.pac with the following content:
### proxy.pac ###
function FindProxyForURL(url, host)
{

/* for *.mydomain.com we connect directly */
if ( isPlainHostName(host) || dnsDomainIs(host, ".mydomain.com")) return
"DIRECT";

/* if we connect to any 10.0.0.0/8 address, it's local net, no proxy */
var localnet = /10\.\d{1,3}\.\d{1,3}\.\d{1,3}/;
if (localnet.test(host)) return "DIRECT";

/* Any connection to 127.0.0.0/8 refers to the local machine.. no proxy */
var hostonly = /127\.\d{1,3}\.\d{1,3}\.\d{1,3}/;
if (hostonly.test(host)) return "DIRECT";

/* by default, we connect to the proxy */
return "PROXY <ip of proxy>:2323"
}
### end proxy.pac ###

The script works as expected in a browser (firefox, internet explorer).
Here follows the output of proxy:
>proxy
http://10.1.2.3
http://<proxyip>:<proxyport>
http://www.google.com
http://<proxyip>:<proxyport>
http://www.mydomain.com
http://<proxyip>:<proxyport>
CTRL-D

As you can see, the proxy ip is reported even for things that would be
excluded by the javascript. So there must be a wrong implementation ay some
point.

Original issue reported on code.google.com by [email protected] on 19 Sep 2008 at 12:22

libproxy should use C89 style comments

The subject is obvious and the patch is attached.
Signed-off By: Jeff Schroeder <[email protected]>

- Changed all C99 style comments to C89 style
- Fixed a small typo in a comment
- Placed TODO on their own line to prevent code churn when they are fixed
- Merged 2 line comments < 78 chars seperated by ','

 bin/proxy.c              |   26 +++---
 lib/array.c              |    7 - 
 lib/config_file.c        |   18 ++--
 lib/misc.c               |   24 +++---
 lib/misc.h               |    2   
 lib/pac.c                |   34 ++++----
 lib/proxy_factory.c      |  155 +++++++++++++++++++++--------------------
 lib/proxy_factory.h      |   16 ++--
 lib/strdict.c            |    2   
 lib/url.c                |   46 ++++++------
 lib/url.h                |    2   
 lib/wpad.c               |    2   
 lib/wpad_dns.c           |   40 +++++-----
 plugins/gnome.c          |   22 ++---
 plugins/kde.c            |   24 +++---
 plugins/mozjs.c          |   22 ++---
 plugins/networkmanager.c |   19 ++---
 plugins/xhasclient.c     |   18 ++--
 18 files changed, 244 insertions(+), 235 deletions(-)

Original issue reported on code.google.com by jeffschroed on 8 Jan 2008 at 7:53

Attachments:

• C99-comments-changed-to-C89-style.patch

major bugfixes to array.c and strdict.c

array.c and strdict.c are pretty messed up.

px_strdict_get() currently returns the strdict's internal key+value array
rather than returning the value itself. This would cause all sorts of
lossage, except for the fact that px_array_add() is broken and increments
self->length *before* adding the new member rather than after, which means
that self->data[0] will always be NULL, which means that px_array_find()
will always return -1 and so px_strdict_get() will always return NULL
(which, in turn means that proxy_factory_misc_get() always returns NULL. Um.)

px_array_del() is also buggy, in that it doesn't decrement self->length,
though since it uses px_array_find(), this doesn't matter much since you
can't delete things anyway.

Given that pxArray keeps track of its length, there's no need to
NULL-terminate the array as well, so I changed it all to not do that (which
as a side benefit means you can also store NULLs in pxArrays now if you want).

I also changed px_strdict_get() to just return NULL if you pass a NULL
strdict, to match px_strdict_set()'s behavior. (This is needed if you have
an empty or unparseable proxy.conf; without this change libproxy will crash
after reading it.)

There should really really be a regression test for these, but I haven't
written one yet.

Original issue reported on code.google.com by [email protected] on 6 Feb 2009 at 5:56

Attachments:

• array-and-dict-fixes.diff

build fails to find dbus.h

Patch attached

Original issue reported on code.google.com by [email protected] on 6 Feb 2009 at 4:31

Attachments:

• dbus-fix.patch

-I misordering can cause compiling to fail

Need to pass all local (source and build dir) -I flags before any -I flags
for external support libraries. Otherwise an existing set of libproxy
headers or the headers for some other thing that happens to have same .h
filename could be found instead of the expected "libproxy that is being
built". It's an easy mistake to make if you aren't careful when reading the
automake manual about the different compiler-flag variables: local -I go in
_CPPFLAGS not _CFLAGS.

Original issue reported on code.google.com by [email protected] on 20 May 2009 at 10:01

Random data returned in plugin networkmanager

A source-Guard while compiling the plugin on openSUSE 11.1 reports:

I: Program returns random data in a function
E: libproxy no-return-in-nonvoid-function networkmanager.c:88

Indeed, the function is defined to have a bool return value, but nothing is
ever returned.

All the other plugins have the function on_proxy_factory_instantiate
defined as void.

I'm just not on a usable internet connection and can thus not commit a fix
for it.

Original issue reported on code.google.com by [email protected] on 20 Oct 2008 at 2:42

Test suite needed

We need to have some method to test our functionality.  A simple shell
script test suite should be sufficient for now.  It should test (at minimum):
1. Using envvar to set config.
2. Each of the ignore patterns outlined at
http://code.google.com/p/libproxy/wiki/IgnorePatterns
3. other stuff?

Original issue reported on code.google.com by [email protected] on 24 Oct 2008 at 2:48

gnome plugin is broken

The gnome plugin causes crashes when used from threaded gnome apps. qv
http://bugzilla.gnome.org/show_bug.cgi?id=571527

The fix here is a bit involved. We need to make sure we never call gconf
from any thread except the main glib thread if there's a main loop running.
This isn't as big a problem as it sounds, because if there's a glib main
loop running, then we can get automatic notifications of gconf key changes
anyway, so we don't need to make gconf calls each time the user tries to
resolve a proxy; we can just always use the last settings we were notified
about. So it's only the initial setup that we need to worry about.

I know how to fix this, but haven't had time to actually write the code.

Original issue reported on code.google.com by [email protected] on 15 Mar 2009 at 2:30

can't mix g_ and non-g_ memory management

glib lets you substitute in an alternate allocator (via
g_mem_set_vtable()), if your app wants to do something funky with memory.
Although this is not widely used, it's still considered wrong to use free()
on memory returned from g_malloc(), or g_free() on memory returned
malloc(), since they might not be equivalent. plugins/gnome.c is very
careless about this.

the patch also fixes a use of "strdup" in lib/misc.c to use px_strdup
instead, to clean up a warning

Original issue reported on code.google.com by [email protected] on 6 Oct 2008 at 5:09

Attachments:

• proxy-mem.diff

curlget sample doesn't handle curl_global_init failing

trunk/src/samples/libcurl/curlget.c
12 int main(int argc, char * argv[]) {
28   /* Initializing curl... has to happen exactly once in the program */
29   curl_global_init( CURL_GLOBAL_ALL );
35     curl_global_cleanup();

http://curl.haxx.se/libcurl/c/curl_global_init.html
RETURN VALUE

If this function returns non-zero, something went wrong and you cannot use
the other curl functions. 

Original issue reported on code.google.com by [email protected] on 6 Nov 2008 at 8:46

proxy command fails in test suite on ubuntu 8.04 and fedora 9, but not ubuntu 8.10

What steps will reproduce the problem?
1.) Update to the latest svn trunk
2.) On Ubuntu 8.04, Ubuntu 8.10, and Fedora 9, build libproxy and then
execute ./runtestsuite.sh

Ubuntu 8.10 looks good and the other distros fail the test. Why?

What is the expected output? What do you see instead?
===== Ubuntu 8.10 =====
TEST NAME            STATUS
proxy_and_lib:           [PASS]
test_env_var1:           [PASS]
=======================

===== Ubuntu 8.04 =====
TEST NAME            STATUS
proxy_and_lib:           [PASS]
*** Unable to locate valid config! Falling back to auto-detection...
*** Unable to locate PAC! Falling back to direct...
test_env_var1:           [FAIL] - src/bin/proxy returned direct:// instead of
http://proxy:1234
=======================

======= Fedora 9 ======
TEST NAME            STATUS
proxy_and_lib:           [PASS]
*** Unable to locate valid config! Falling back to auto-detection...
*** Unable to locate PAC! Falling back to direct...
test_env_var1:           [FAIL] - src/bin/proxy returned direct:// instead of
http://proxy:1234
=======================

The actual command being ran is:
PX_CONFIG_ORDER=envvar http_proxy="http://proxy:1234" src/bin/proxy
http://www.google.com

Original issue reported on code.google.com by jeffschroed on 17 Dec 2008 at 6:00

proxy authentication

Some proxies require authentication. libproxy does not currently handle this.

The easiest change would be to just declare that the proxy URIs returned
from px_proxy_factory_get_proxies() might include a username and password
(ie, http://user:pass@host:port). Indeed, it seems that some apps already
handle that syntax in the http_proxy environment variable, and KDE also
allows its use in the kioslaverc httpProxy key.

However, libproxy won't currently allow a backend to give it URIs
containing username and password, because pxURL won't accept them.

I can update pxURL to deal with this if you want. It's a biggish change
though, since pxURL would have to be able to deal with %-encoded URL
elements now, since the password might have a "@" or "/" in it.

I already have a patch to make the GNOME backend return auth info in this
format, but it doesn't work because of the pxURL problems.

Original issue reported on code.google.com by [email protected] on 6 Oct 2008 at 5:47

Attachments:

• gnome-proxy-auth.diff

remove use of _POSIX_C_SOURCE

On Solaris, libproxy fails to build with the following error:

/usr/include/sys/feature_tests.h:353:2: #error "Compiler or options invalid
for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"

_POSIX_C_SOURCE should not be defined to 1. The Sun-distributed version
patches this define out in configure.ac:
http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/libproxy-05-
config-posix.diff

Applying this patch to SVN head allows successful builds on Solaris.

Original issue reported on code.google.com by [email protected] on 3 May 2009 at 2:54

libproxy doesn't build with LDFLAGS="--as-needed"

What steps will reproduce the problem?
1. configure with LDFLAGS="--as-needed"
2. make
3. see it FAIL with 
gcc -I../../src/lib -g -std=c99 -g3 -O0 -pipe
-DPLUGINDIR=\"/usr/local/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/local/etc\" -D_POSIX_C_SOURCE=1 -Wl,-O0
-Wl,--enable-new-dtags -Wl,--sort-common -Wl,--as-needed -o .libs/proxy
proxy-proxy.o  -ldl -L/opt/gnome2/lib64 ../lib/.libs/libproxy.so -lm 
-Wl,--rpath -Wl,/usr/local/lib
../lib/.libs/libproxy.so: undefined reference to `dlsym'
../lib/.libs/libproxy.so: undefined reference to `dlerror'
../lib/.libs/libproxy.so: undefined reference to `dlopen'
../lib/.libs/libproxy.so: undefined reference to `dlclose'
collect2: ld returned 1 exit status

What is the expected output? What do you see instead?
I expected it to compile fine.

What version of the product are you using? On what operating system?
0.3.2 on Fedora 10

Please provide any additional information below.
I removed the --as-needed flag and it works!
So the fix must be to add -ldl to the compiling flags.

Original issue reported on code.google.com by [email protected] on 5 Feb 2009 at 10:59

NM manager pkg-config libs detection needs dbus-1.0 to be added

What steps will reproduce the problem?
1. build libproxy with NM plugin enabled (on Fedora)
2.
3.

What is the expected output? What do you see instead?
If dbus-1.0 isn't added the networkmanager module doesn't have any chances
to build since the dbus headers cannot be found.

What version of the product are you using? On what operating system?
Fedora 8/9/rawhide
Which in Fedora 8 NetworkManager-0.7.0-0.6.9.svn3675.fc8


Please provide any additional information below.
libproxy package is been reviewed for introduction in the Fedora repositories:
https://bugzilla.redhat.com/show_bug.cgi?id=457035

Original issue reported on code.google.com by [email protected] on 4 Aug 2008 at 10:12

Attachments:

• libproxy-0.2.3-dbus.patch

libproxy ignores --without-python to configure

Hence, python bindings are built regardless of whether you want them or not.

Attached is a patch to fix this in configure.ac

Original issue reported on code.google.com by [email protected] on 30 Jan 2009 at 9:30

Attachments:

• libproxy-0.2.3-fix-python-automagic.patch

proxy program always fails to parse URL.

What steps will reproduce the problem?
1. Invoke /usr/bin/proxy
2. Type a URL, e.g. http://foo

What is the expected output? What do you see instead?
http://foo is parsed correctly

What version of the product are you using? On what operating system?
0.2.3, OpenSolaris

Please provide any additional information below.
This is caused by the parsed string is not correct in readline().
The end of char needs '\0'. I'm attaching the patch.

Original issue reported on code.google.com by takao.fujiwara1 on 13 Feb 2009 at 6:35

Attachments:

• libproxy-03-proxy-readline.diff

python bindings does not work under Solaris

What steps will reproduce the problem?
1. create python file a.py with following contents:

import libproxy

URL = "http://www.google.com"

pf = libproxy.ProxyFactory()
for proxy in pf.getProxies(URL):
  print proxy


What is the expected output? What do you see instead?
expected: the proxy I set
actually: raise a error said ctypes.util.find_library cannot find the
related library

What version of the product are you using? On what operating system?
0.2.3

Please provide any additional information below.

I hard code the library path as "libproxy.so".
Just a work-around.

Original issue reported on code.google.com by [email protected] on 16 Feb 2009 at 8:19

Attachments:

• libproxy-04-py-find-lib.diff

dlopen fails on 64bit

What steps will reproduce the problem?
1. compile libproxy on x86_64
2. start proxy test application
3. let it tell you what proxy to use

What is the expected output? What do you see instead?
I'd expect it to tell me the content of http_proxy, instead it replies
direct://

What version of the product are you using? On what operating system?
0.2.2

Please provide any additional information below.
gdb output when starting proxy shows:

(gdb) run
Starting program: /usr/local/bin/proxy 
attemtping to load library '/usr/local/lib/libproxy/0.2.2/plugins/..'
attemtping to load library '/usr/local/lib/libproxy/0.2.2/plugins/gnome.so'
[Thread debugging using libthread_db enabled]
[New Thread 47571375363824 (LWP 18638)]
Error while reading shared library symbols:
Cannot find new threads: generic error

Original issue reported on code.google.com by [email protected] on 3 Jun 2008 at 8:22

Implement CIDR notation on ProxyIgnore pattern

If a proxy ignore of 127.0.0.0/8 is configured, this is ignored at the
moment by libproxy.

127.0.0.0/255.0.0.0 would work.

For the 0.3 release, also CIDR (on ipv4 and ipv6) should be functional.

Original issue reported on code.google.com by [email protected] on 23 Oct 2008 at 6:56

libproxy should specify the proxy type

libproxy should specify the type of proxy it is using ie: SOCKS(4|5), HTTP,
etc.

Please provide any additional information below.
http://article.gmane.org/gmane.comp.gnome.gaim.devel/13533

Original issue reported on code.google.com by jeffschroed on 8 Jan 2008 at 7:21

Python-bindings misload libpython and misuse PyMem_Free

The libproxy.py section:

# Load libpython (for a cross platform 'free()')

does not work for me...can't find the lib. My python-2.6 shared library is
not in a standard dyld location and is not called libpython2.6 or
libpython26. Even if I did, I might be actually running a
third-party-supplied python in /opt or somewhere else non-dyld-standard, so
this search would find the wrong one entirely. Heck, until recently, my
vendor didn't even supply a shared lib at all (only static). So firstly,
this search approach is non-portable.

Secondly, PyMem_Free is the free() that is used by libpython itself. I
might have an alternate malloc()/free() in some lib that overlays the
normal one (via -L and -l flags, for example), so no guarantee that
libpython's memory-handlers match the ones in my C/C++ realm used by the
compiled libproxy shared lib, and no way to pass standard flags to libproxy
resolve that mis-match. I talked to #python channel on freenode, who
mentioned these problems and that this whole approach is kinda doomed even
if libpython were able to be found reliably.

The clean solution is to rewrite the python bindings for this compiled
library as a compiled in C python module rather than pure .py, so you get
standard C memory handlers (and compiler flags to control them) for
self-consistency.

Original issue reported on code.google.com by [email protected] on 20 May 2009 at 9:51

Disable WPAD DNS devolution by default

The attached patch against trunk disables WPAD DNS devolution by default.
It can be activated at build time by passing --with-wpad-dns to configure.

This is to address some security implications DNS proxy devolution has. See
for example:

http://lists.debian.org/debian-devel/2008/12/msg00730.html (full thread)
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol#Security

Original issue reported on code.google.com by [email protected] on 7 Jan 2009 at 9:50

Attachments:

• libproxy_disable_wpad_dns_devolution_by_default.patch

bin/proxy segfaults

#> PX_CONFIG_ORDER=envvar http_proxy="http://proxy:1234" gdb proxy

GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
(gdb) run http://www.google.com
Starting program: /usr/local/bin/proxy http://www.google.com
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7282677 in strstr () from /lib64/libc.so.6
(gdb) bt full
#0  0x00007ffff7282677 in strstr () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007ffff7bd99b8 in px_strsplit (string=0x0, delimiter=0x7ffff7bdc2d4
",") at misc.c:169
    tmp = 0x0
    count = 1
    strv = (char **) 0x603010
    last = <value optimized out>
#2  0x00007ffff7bdaab9 in px_proxy_factory_get_proxies (self=0x603010,
url=<value optimized out>) at proxy_factory.c:256
    response = (char **) 0x6038b0
    confurl = 0x603fa0 "http://proxy:1234"
    confign = 0x0
    config = (pxConfigPlugin *) 0x6035f0
    realurl = (pxURL *) 0x6039f0
    ignores = <value optimized out>
#3  0x0000000000400e83 in main (argc=2, argv=<value optimized out>) at
proxy.c:115
    i = 2
    pf = <value optimized out>
(gdb) print strv[1]
No symbol "strv" in current context.
(gdb) 

Original issue reported on code.google.com by [email protected] on 16 Mar 2009 at 7:51

[deleted issue]

[deleted issue]

Admin should forbid or force somme stuff

As asked on debian list, you should provide a means to the system admin to
force user choice. For instance if admin want to forbid wpad, it should
force user to not use it.

Because your package could have security implication, it is really
important to implement this policy.

A deny and allow section will be the best stuff to do

Regards 

Bastien

Original issue reported on code.google.com by [email protected] on 18 Jan 2009 at 10:30

issues with proxy.pac

Gnome is configured to read the proxy settings from a pac file:
http://1.2.3.4/proxy.pac

This setting works, the pac is valid and distributed as
application/x-ns-proxy-autoconfig mime type

When using proxy (the test program from libproxy), I get the following output :

>proxy
http://www.google.com
*** Invalid PAC URL! Falling back to direct...
direct://

This is apparently not such a nice solution (especially not, as all other
programs seem to work fine with this pac file).

If I can provide you any more information, please let me know.

Original issue reported on code.google.com by [email protected] on 10 Sep 2008 at 1:10

Portability problems in libproxy 0.2.3

1) 'test STR = STR' is the portable way to check whether strings are 
identical. See 'man 1 test'. 'STR == STR' just happens to work with some 
shells' builtin test.

2) Not all systems have libdl (only Linux and Solaris AFAIK).

3) arpa/inet.h isn't enough for 'struct sockaddr_in(6)', netinet/in.h 
must be included. Again, it just happens to work on some systems like 
Linux because arpa/inet.h just includes netinet/in.h there.

http://www.opengroup.org/onlinepubs/009695399/basedefs/arpa/inet.h.html
http://www.opengroup.org/onlinepubs/009695399/basedefs/netinet/in.h.html

The attached patch fixes these problems. Tested in Debian Linux and 
DragonFly BSD.

Original issue reported on code.google.com by [email protected] on 12 Mar 2009 at 1:22

Attachments:

• libproxy-0.2.3.patch

curlget sample / socks implementation

      /* SOCKS Proxy, is this correct??? */
      /* What about SOCKS 4A, 5 and 5_HOSTNAME??? */
      else if (!strncmp("socks", proxies[i], 4))
        curl_easy_setopt(curl, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);

This is only supposed to work if the URL was based on an IP Address. only
SOCKS 4A supports name resolution by the socks server.

Firefox defaults to use SOCKS5, but there again, only SOCKS5_HOSTNAME would
be able to resolve the name. Servers seem mostly to be implemented in
SOCKS4 or SOCKS5 (without name resolution).

Original issue reported on code.google.com by [email protected] on 21 Oct 2008 at 8:37

provide pkg-config for libproxy

Not all distros like to provide header files in /usr/include. Fedora moved
it to /usr/include/libproxy.

This is an issue for all applications simply linking against libproxy, as
#include <proxy.h> won't find the include file.

By providing a pkg-config file we can help this situation out.

Original issue reported on code.google.com by [email protected] on 16 Mar 2009 at 10:44

Making Error: Arch Linux

I'm trying to make 'libproxy' v0.2.3 on Arch Linux using the following method:

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  ./configure --prefix=/usr --without-mozjs || return 1
  make || return 1
  make DESTDIR="${pkgdir}" install || return 1
}

I'm unfortunately receiving the following error message, which I'm
wondering how to overcome:

creating kde.la                                                           


(cd .libs && rm -f kde.la && ln -s ../kde.la kde.la)
/bin/sh ../../libtool --tag=CC   --mode=compile gcc
-DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\"
-DPACKAGE_VERSION=\"0.2.3\" -DPACKAGE_STRING=\"libproxy\ 0.2.3\"
-DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"libproxy\"
-DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1
-DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I.    -I../../src/lib
-I/usr/include/NetworkManager   -g -std=c99 -march=i686 -mtune=generic -O2
-pipe -DPLUGINDIR=\"/usr/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/etc\" -D_POSIX_C_SOURCE=1 -MT
networkmanager_la-networkmanager.lo -MD -MP -MF
.deps/networkmanager_la-networkmanager.Tpo -c -o
networkmanager_la-networkmanager.lo `test -f 'networkmanager.c' || echo
'./'`networkmanager.c         
 gcc -DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\"
-DPACKAGE_VERSION=\"0.2.3\" "-DPACKAGE_STRING=\"libproxy 0.2.3\""
-DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"libproxy\"
-DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1
-DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I. -I../../src/lib
-I/usr/include/NetworkManager -g -std=c99 -march=i686 -mtune=generic -O2
-pipe -DPLUGINDIR=\"/usr/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/etc\" -D_POSIX_C_SOURCE=1 -MT
networkmanager_la-networkmanager.lo -MD -MP -MF
.deps/networkmanager_la-networkmanager.Tpo -c networkmanager.c  -fPIC -DPIC
-o .libs/networkmanager_la-networkmanager.o                               

networkmanager.c:27:23: error: dbus/dbus.h: No such file or directory     


networkmanager.c: In function 'nm_on_get_proxy':                          


networkmanager.c:34: error: 'DBusConnection' undeclared (first use in this
function)                                                                 

networkmanager.c:34: error: (Each undeclared identifier is reported only once
networkmanager.c:34: error: for each function it appears in.)
networkmanager.c:34: error: 'conn' undeclared (first use in this function)
networkmanager.c:35: warning: implicit declaration of function
'dbus_connection_get_is_connected'
networkmanager.c:41: warning: implicit declaration of function
'dbus_connection_close'
networkmanager.c:42: warning: implicit declaration of function
'dbus_connection_read_write'
networkmanager.c:43: error: 'DBusMessage' undeclared (first use in this
function)
networkmanager.c:43: error: 'msg' undeclared (first use in this function)
networkmanager.c:43: warning: implicit declaration of function
'dbus_connection_pop_message'
networkmanager.c:43: warning: implicit declaration of function
'dbus_message_unref'
networkmanager.c:47: warning: implicit declaration of function
'dbus_bus_get_private'
networkmanager.c:47: error: 'DBUS_BUS_SYSTEM' undeclared (first use in this
function)
networkmanager.c:51: warning: implicit declaration of function
'dbus_connection_set_exit_on_disconnect'
networkmanager.c:52: warning: implicit declaration of function
'dbus_bus_add_match'
networkmanager.c:53: warning: implicit declaration of function
'dbus_connection_flush'
networkmanager.c:72: warning: implicit declaration of function
'dbus_message_get_args'
networkmanager.c:72: error: 'DBUS_TYPE_UINT32' undeclared (first use in
this function)
networkmanager.c:72: error: 'DBUS_TYPE_INVALID' undeclared (first use in
this function)
networkmanager.c: In function 'on_proxy_factory_destantiate':
networkmanager.c:94: error: 'DBusConnection' undeclared (first use in this
function)
networkmanager.c:94: error: 'conn' undeclared (first use in this function)
make[3]: *** [networkmanager_la-networkmanager.lo] Error 1
make[3]: Leaving directory
`/tmp/yaourt-tmp-chris/aur-libproxy/libproxy/src/libproxy-0.2.3/src/plugins'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/tmp/yaourt-tmp-chris/aur-libproxy/libproxy/src/libproxy-0.2.3/src/plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/tmp/yaourt-tmp-chris/aur-libproxy/libproxy/src/libproxy-0.2.3/src'
make: *** [all-recursive] Error 1

Original issue reported on code.google.com by [email protected] on 22 Feb 2009 at 3:44

libproxy doesn't compile under Solaris

libproxy doesn't compile under Solaris with Sun Studio.

Attached the patch.

Original issue reported on code.google.com by [email protected] on 13 Feb 2009 at 8:41

Attachments:

• libproxy-01-orig-build.diff

libproxy does not include dbus headers with the networkmanager plugin enabled

./configure --with-networkmanager
<finishes nicely>

---------
$ make
/bin/sh ../../libtool --tag=CC   --mode=compile gcc
-DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\"
-DPACKAGE_VERSION=\"0.2.3\" -DPACKAGE_STRING=\"libproxy\ 0.2.3\"
-DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"libproxy\"
-DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1
-DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I.    -I../../src/lib
-I/usr/include/NetworkManager   -g -std=c99 -g -O2
-DPLUGINDIR=\"/usr/local/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/local/etc\" -D_POSIX_C_SOURCE=1 -MT
networkmanager_la-networkmanager.lo -MD -MP -MF
.deps/networkmanager_la-networkmanager.Tpo -c -o
networkmanager_la-networkmanager.lo `test -f 'networkmanager.c' || echo
'./'`networkmanager.c
 gcc -DPACKAGE_NAME=\"libproxy\" -DPACKAGE_TARNAME=\"libproxy\"
-DPACKAGE_VERSION=\"0.2.3\" "-DPACKAGE_STRING=\"libproxy 0.2.3\""
-DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"libproxy\"
-DVERSION=\"0.2.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1
-DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -I. -I../../src/lib
-I/usr/include/NetworkManager -g -std=c99 -g -O2
-DPLUGINDIR=\"/usr/local/lib/libproxy/0.2.3/plugins\"
-DSYSCONFDIR=\"/usr/local/etc\" -D_POSIX_C_SOURCE=1 -MT
networkmanager_la-networkmanager.lo -MD -MP -MF
.deps/networkmanager_la-networkmanager.Tpo -c networkmanager.c  -fPIC -DPIC
-o .libs/networkmanager_la-networkmanager.o
networkmanager.c:27:23: error: dbus/dbus.h: No such file or directory
networkmanager.c: In function 'nm_on_get_proxy':
networkmanager.c:34: error: 'DBusConnection' undeclared (first use in this
function)

<more errors snipped>

Reproduced on a Gentoo x86 2008.0 system running GNOME 2.24 and dbus 1.2.3
dbus header files are in /usr/include/dbus-1/. Which is why it fails.

Attached is a patch to configure.ac to check for dbus and add dbus_CFLAGS
to NETWORKMANAGER_CFLAGS

Original issue reported on code.google.com by [email protected] on 30 Jan 2009 at 9:24

Attachments:

• libproxy-0.2.3-fix-dbus-includes.patch

Interface should be declared extern "C"

All C Interfaces always need 'extern "C"', otherwise they cannot be used
from C++.

What steps will reproduce the problem?
  1. g++ test.cxx -I. -lproxy -ldl
(where test.cxx is any simple program that uses the library)

What is the expected output?
  Expected: works

What do you see instead?
  Seen:

/tmp/ccMGVQ2H.o: In function `proxy::Unix::Unix()':                       

test.cxx:(.text._ZN5proxy4UnixC1Ev[proxy::Unix::Unix()]+0x24): undefined
reference to `px_proxy_factory_new()'                                     

[...]

What version of the product are you using?
  libproxy-0.2.3.tar.gz

On what operating system?
  Any (Linux)

--------------------------------------------------------------
Please provide any additional information below.

In proxy.h, all the declarations must be inside:

#ifdef __cplusplus
extern "C"
{
#endif

[...] // your interface declarations here

#ifdef __cplusplus
}
#endif

Otherwise the library cannot be used in a C++ program.

--------------------------------------------------------------

Quick fix for those who need it now, without editing proxy.h:

#ifdef __cplusplus
extern "C" {
  #include <proxy.h>
}
#else
#include <proxy.h>
#endif

Original issue reported on code.google.com by [email protected] on 9 Mar 2009 at 1:19