ERROR: Could not find X Window System headers/libraries

help me install rdesktop on my sled 11 sp3 desktop machine.

 ./configure 
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for X... no

ERROR: Could not find X Window System headers/libraries.
To specify paths manually, use the options --x-includes and --x-libraries.

Have you tried using FreeRDP? rdesktop was removed from SLED as of 11 SP3 in favour of FreeRDP. The executable is xfreerdp. If you don’t have that install the freerdp package.

If you want rdesktop there is a package for SUSE SLE-11 SP 3 available at http://software.opensuse.org/package/rdesktop

If you want to build from source the -devel package(s) you need (start with xorg-x11-devel) are probably in the SLE SDK. The appropriate version for SLED 11 SP3 is at
https://download.suse.com/Download?buildid=hF8sRGTVC04~

Actually I need the local device(printer) during the remote session, which rdesktop provides/supports via ‘-r’ option, and I don’t find this local resource feature in FreeRDP.

Also rather downloading the 11 SP 3 SDK, I installed the rdesktop rpm from SLED 11 SP2 media without any issue, and its working too. But -r option does not seem to work, because when I logs on my Windows Server via rdp, I don’t see the local printer their, so it seems rdesktop is not properly working with respect to local printer availability, also its not just SLED rdesktop, but -r option doesn’t seem to work on ubuntu boxes too.

Remmina is working, but Remmina is not available for SLED 11.

[QUOTE=sharfuddin;21474]Actually I need the local device(printer) during the remote session, which rdesktop provides/supports via ‘-r’ option, and I don’t find this local resource feature in FreeRDP.
[/QUOTE]

Try these options

 --plugin rdpdr --data printer --

See also rdpdr section at

https://github.com/FreeRDP/FreeRDP/wiki/Plugins

Thanks for suggesting me the --plugin option. I tried ‘–plugin rdpdr’ but it does not work, i.e when I try to print a document on windows terminal server, I dont find the printers attached/installed on SLED box.

xfreerdp 192.168.0.199  --plugin rdpdr --data printer -- 
.
.
debug1: channel 1: free: x11, nchannels 4
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 49501
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
xkbLayout: us	xkbVariant: 
debug1: channel 1: free: x11, nchannels 4
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 49502
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 4
xkbLayout: us	xkbVariant: 
find_keyboard_layout_in_xorg_rules: 409
detect_keyboard_layout_from_locale: 409
Using US (0x00000409)
Loading keymap evdev
xkbfilepath: /usr/share/freerdp/keymaps/evdev
Loading keymap aliases(qwerty)
xkbfilepath: /usr/share/freerdp/keymaps/aliases
kbd_init: detect_and_load_keyboard returned 1033
freerdp_kbd_init: 409
starting thread 0 to 192.168.0.199:3389
[I][COLOR="#FF0000"]freerdp_chanman_load_plugin: filename rdpdr
freerdp_chanman_load_plugin: /usr/lib64/freerdp/rdpdr.so
loaded device service: /usr/lib64/freerdp/disk.so
printer_register: EpsonR210 (default=1)
printer_hw_new: use CUPS API 1.2
printer_register: hp (default=0)
printer_hw_new: use CUPS API 1.2
loaded device service: /usr/lib64/freerdp/printer.so
loaded device service: /usr/lib64/freerdp/serial.so
loaded device service: /usr/lib64/freerdp/parallel.so
[/COLOR][/I]MyVirtualChannelInit:
full screen option
missing server name
main thread, waiting for all threads to exit
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 49503
debug1: channel 1: new [x11]
debug1: confirm x11
freerdp_chanman_pre_connect:
keyboard_layout: 409
connecting to 192.168.0.199:3389
Error: SSL_NOT_ALLOWED_BY_SERVER
connecting to 192.168.0.199:3389
freerdp_chanman_post_connect: server name [192.168.0.199] chan_man->num_libs [0]
xf_handle_event: ClientMessage user quit received
run_xfreerdp: xf_check_fds failed
debug1: channel 1: FORCE input drain
main thread, all threads did exit

Unfortunately I’ve been unable to get printer redirection to work either. I’m thought I had it working once before though.

I was going to try with newer version of FreeRDP but building those requires newer things than are in SLED 11 SP3.

xfreerdp is sensitive regarding the options. I was providing the options after Server Address, while xfreerdp expects the option before Server Address, so following does not work:

xfreerdp 192.168.0.199  --plugin rdpdr --data printer -- 

But following works perfectly:

xfreerdp --plugin rdpdr --data printer -- 192.168.0.199

Once again thanks a lot mikewillis.

Regards,
MS

Excellent. Thanks for posting back that you got it working and, much more importantly, how you got it working!

It works for me too with the options before the hostname.

Now I look again, the Wiki page I linked to actually shows that in the usage example. Doh.