X11R6?

I am trying to compile/install pgm last built from wheezy onto a rpi running buster os. The make and Makefile refer to /usr/X11R6 which doesn't exist in buster. What to do? (pgm in question is gsport-0.31, a apple IIGS emulator). file vars links to vars_pi. --Steven

Reply to
nelsonse48
Loading thread data ...

You've probably got directories such as /usr/bin/X11 and /usr/include/X11. /usr/X11R6 is supposed to include those same directories, like this:

$ ls /usr/X11R6 bin include lib man share

So if it's not easy to adapt the Makefile to using the X11 directories, you want to make a /usr/X11R6 directory and symlink all the /usr/bin/X11 directories inside there, eg. $ sudo mkdir /usr/X11R6 $ sudo ln -s /usr/bin/X11 /usr/X11R6/bin $ sudo ln -s /usr/include/X11 /usr/X11R6/include etc.

Of course you'll want to install the -dev package for Xorg as well.

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

Thank you Kev(?). I think I have the X11 issue resolved. But 'make' still doesn't make it (punny).

pi@raspberrypi4:~/gsport-0.31/src $ make g++ -O2 -Wall -fomit-frame-pointer -std=gnu99 -march=armv6 adb.o clock .o config.o dis.o engine_c.o scc.o iwm.o joystick_driver.o moremem.o paddle s.o parallel.o printer.o sim65816.o smartport.o sound.o sound_driver.o vide o.o scc_socket_driver.o imagewriter.o scc_imagewriter.o scc_llap.o tfe/tfe. o tfe/tfearch.o tfe/tfesupp.o atbridge/aarp.o atbridge/atbridge.o atbridge/ elap.o atbridge/llap.o atbridge/port.o atbridge/pcap_delay.o xdriver.o com pile_time.o -o gsportx -L/usr/X11R6/lib -lXext -lX11 /usr/bin/ld: atbridge/pcap_delay.o: undefined reference to symbol 'dlopen@@ GLIBC_2.4' /usr/bin/ld: //lib/arm-linux-gnueabihf/libdl.so.2: error adding symbols: DS O missing from command line collect2: error: ld returned 1 exit status make: *** [Makefile:66: gsportx] Error 1 pi@raspberrypi4:~/gsport-0.31/src $

I have no idea where to debug. --Steven

Reply to
nelsonse48

Does this help?

formatting link

Reply to
Dr Eberhard W Lisse

Sorry, the ivanx and dschmenk scripts are intended for Debian 7 (wheezy). Buster is Debian 10. The 2013 instructions no longer work! But thanks for looking. --Steven

Reply to
nelsonse48

Well the linker is missing a library that the source code requires, adding "-ldl" to the end of the g++ command should work. If it has a common sort of configure script, try: $ LIBS=-ldl ./configure [any other args that you've been using]

If it's a handmade Makefile, you'll just have to find where "-lXext -lX11" is specified and add " -ldl" on the end.

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

ock.o config.o dis.o engine_c.o scc.o iwm.o joystick_driver.o moremem.o pad dles.o parallel.o printer.o sim65816.o smartport.o sound.o sound_driver.o v ideo.o scc_socket_driver.o imagewriter.o scc_imagewriter.o scc_llap.o tfe/t fe.o tfe/tfearch.o tfe/tfesupp.o atbridge/aarp.o atbridge/atbridge.o atbrid ge/elap.o atbridge/llap.o atbridge/port.o atbridge/pcap_delay.o xdriver.o c ompile_time.o -o gsportx -L/usr/X11R6/lib -lXext -lX11

en@@GLIBC_2.4'

: DSO missing from command line

Thank you! That solved the make errors. But the resulting executable (gsp ortx) fails with a segmentation fault. Grrr --Steven

Reply to
nelsonse48

Ah, well that will probably be a bit more in-depth to fix. The only easy option might be if there's a current package for some other Linux or BSD, the package maintainers might have already made their own patch to get around that problem.

Otherwise you could report a bug to the software's author, or try debugging the code yourself.

If you can turn off features with command-line arguments to gsportx, maybe see if you can get it to avoid the bit of code causing the seg fault.

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

From time to time I admire this news group/mailing list. OP is trying to compile something that was working in Wheezy for Buster!!! Do you know when Wheezy went out of support? Do you know how Debian changed meanwhile? I see last update of this code was 2017 and it is written for x86. So you have to rework a lot of the code and the autotool files to make it work. This means if you do not understand programming, better leave it. If you understand programming ... well you wouldn't be writing here :)

I suggest you git clone

formatting link
and try your luck. Chances to succeed are much higher. Note that this is x86 code and you have to add x86 to the system. Install the required dev packages (basically follow the README). Good luck

Reply to
Deloptes

Welcome to version, and dependency, hell.

--
The theory of Communism may be summed up in one sentence: Abolish all  
private property. 
 Click to see the full signature
Reply to
The Natural Philosopher

I bet the link I sent would be more usable than his code copy from 2017 ;-)

this is like complaining that my sons shoes from 3y ago do not fit him anymore. Well, children grow up so does software. It is very hard to keep up with all the changes

Reply to
Deloptes

Well the homepage describes build instructions for the Raspberry Pi, and unless a program is written in assembly there's no immediate reason to assume it won't build on ARM even if only tested on x86 by the developer.

Actually this reminds me (especially the topic name) of my recent attempts building XFree86 for the Pi Zero running Raspbian Buster. That software hasn't been updated since before Raspberry Pis even existed, and although it supposably supported building on ARM, this turned out to be broken in the last release (or else GCC worked _very_ differently with certain bits of code back then). After working through a much longer string of similar problems (first just trying to build the Makefiles), and even a similar seg fault problem, I did get it running in the end. I've got a very long log of all the changes I had to make - being able to compare code with Xorg offered a good way to cheat, except where subsystems had been completely rewritten since XFree86.

One hopes that an emulator like this would be a lot easier than that though. XFree86 ties into a lot of lower-level stuff which is more architecture-dependent than most other software needs to be. Plus it's HUGE (the Makefiles still had rules for building on a 486

- I can only assume that those people are still waiting for it to finish compiling :) ).

--
__          __ 
#_ < |\| |< _#
Reply to
Computer Nerd Kev

Only if it hasn't made assumptions about x86 structure packing, non-aligned accesses, and a lot of other subtle architecture pitfalls.

---druck

Reply to
druck

+10001 However that may not stop it building - just working :-)

--
Future generations will wonder in bemused amazement that the early  
twenty-first century?s developed world went into hysterical panic over a  
 Click to see the full signature
Reply to
The Natural Philosopher

FYI - it is important when compiling for a given shared lib (in this case, X11) to install the "-dev" packages associated with it. I forget which ones (exactly) are needed, but if you were to install the dependencies for building gtk I bet it would be enough [or very close].

try "apt-get build-dep libgtk2.0-dev"

it's a lot, I know, but the libs you end up getting the -dev packages for are the ones that are a) likely to be installed, and b) probably needed for most X11 applications

--
(aka 'Bombastic Bob' in case you wondered) 

'Feeling with my fingers, and thinking with my brain' - me 
 Click to see the full signature
Reply to
Big Bad Bob

right - and that's probably the most important part

NOTE: I tested this - "apt-get build-dep libgtk2.0-dev"

I think it includes all of the most popular libs for -dev packages. The default RPi includes gtk2 and the dev package needs "all that" to build. It was around 600Mb when I just tested it on a different Linux system (based on Debian Buster). RPi is usually very similar. But I think i already installed all of the -dev packages on my RPi systems...

--
(aka 'Bombastic Bob' in case you wondered) 

'Feeling with my fingers, and thinking with my brain' - me 
 Click to see the full signature
Reply to
Big Bad Bob

Make sure you have 'build-essential' too. You won't get far without it!

--
W J G
Reply to
Folderol

didn't I mention it earlier? thanks, though, it IS important

Reply to
Big Bad Bob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.