libproxy doesn't compile under Solaris

[markcox]

libproxy doesn't compile under Solaris

[GoogleCodeExporter]

Ke,

Thank you very much for your patch. We are highly interested in successfully 
porting
libproxy over to opensolaris.

Even though your patch might solve the compiling issues you experienced, it 
does not
conform to our expectations we have.

Some comments:
-Wall should not be disabled unconditionally. Much better would be to actually 
solve
the warnings we might experience at this time on opensolaris. Or at least only
disable -Wall on opensolaris.

The inclusion of -lsocket should be triggered if possible by a configure check 
if
needed. Otherwise it should be skipped.

The extension of the empty stucts is a different story. I understand that an 
empty
struct does not conform and your compiler is strict on this. Only DNS WPAD is
implemented at this time. It would be better to disable the other two WPAD 
solutions
(SLP and DHCP) instead of extending their structs with dummies just to let them
compile. Anyhow there is no function in there yet.

Do you think you can update your patch according to those comments? We 
appreciate
your work.

Original comment by [email protected] on 13 Mar 2009 at 7:36

[GoogleCodeExporter]

Original comment by [email protected] on 19 Mar 2009 at 2:00

• Changed state: Accepted

[GoogleCodeExporter]

The empty structs no longer exist in SVN Trunk (only wpad_dns and the new
wpad_dnsdevolution) plugin are now available. wpad_slp and wpad_dhcp are 
removed for
the time being, rendering this part of the patch obsolete.

Original comment by [email protected] on 21 Mar 2009 at 10:27

[GoogleCodeExporter]

svn rev 330 adds logic to auto-detect if libsocket is required on a system or 
not.
The empty structs have been removed with the complete rewrite of the plugin 
manager
and -Wall can now stay used in the build. 

So I think this should be solved. 

Original comment by [email protected] on 22 Mar 2009 at 4:33

• Changed state: Fixed

[GoogleCodeExporter]

Issue 52 has been merged into this issue.

Original comment by [email protected] on 19 Jun 2009 at 7:15