Shop OBEX P1 Docs P2 Docs Learn Events
Is BST dead? — Parallax Forums

Is BST dead?

Heater.Heater. Posts: 21,230
edited 2013-04-12 17:24 in Propeller 1
Edit: The conclusion of this thread is that bst-0.19.4-pre13 does not run on my Debian Wheezy amd64 machine. Versions prior to that are OK!



I use BST. I like BST. BST is what allowed me to use the Propeller (The Prop Tool only works on Windows). BST has features I make use of, #defines, optimizations etc.

BradC did a wonderful job with BST and a great service to the Propeller community.

However. I now have a 64 it installation of Debian here and BST won't run.

Now in theory I can run 32 bit code on this machine. Just need to install all the required 32 bit libraries. Something like:

$ dpkg --add-architecture i386

Then figure out all the libs it needs, then find the package they are contained in, then install them, perhaps like:

$ apt-get install libX11:i386

and so on. And then figure out why it probably still does not run, as is the way with these things.

You know what? I really don't want to do that.

And so, like all closed source software, BST has finally died for me.

Just now I have no Spin support! BST won't run and the new opensource Spin does not have the extra features my projects use. It's kind of buggered up my weekends hacking.

It is a sad day here.
«1345

Comments

  • DavidZemonDavidZemon Posts: 2,973
    edited 2013-03-31 01:31
    Been running 64-bit Ubuntu for quite some time and had no problems at all with BST. Perhaps Ubuntu packages a few extra things together for me to make it a little less painful... not sure? Have you tried running BST yet?
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-31 02:13
    heater: Have you checked to see if homespun works? Homespun is used to compile catalina files and has most features of bst plus include. I am not sure if it was a windoze only compiler. I can email Michael if need be to ask.
    I am in the processof trying to contact Brad. If I get a reply I will ask him for you.
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 02:22
    SwimDude,

    Yeah, I'm pretty sure Ubuntu comes loaded up with all 32 bit compatibility libs. Ubuntu however always gives me a lot of trouble in other ways. It is after all based off the "testing" (i.e. not ready for release) versions of Debian with Ubuntus own bugs added on top.

    BST does not run here, too many 32 bit graphical libs required. BUT the good news is that the command line compiler BSTC does work. And that is what SimpleIDE uses. Only problem is I can't get my SimpleIDE working correctly yet but that's another story.

    Cluso,

    Oh yes, I forgot about HomeSpun. Now you mention it I will have to give it a try on this new box.

    Do say "Hello" to Brad from us all.



    Edit: SimpleIDE works just fine with BSTC. I was just suffering from disiconia, I can't read icons. If the friggin buttons were labeled "Build" and "Settings" etc I might have more chance hitting the right ones:)
    Anyway all works, my weekend is saved.
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 02:43
    Cluso,

    homespun works just fine here on 64 bit Debian Wheezy.

    Edit: Forgot to say. HomeSpun is written in C# and hence runs under the mono .NET run time.

    As a result it runs on most Linux boxes even my ARM based boards including the Raspberry Pi.
  • TorTor Posts: 2,010
    edited 2013-03-31 04:30
    Heater. wrote: »
    Now in theory I can run 32 bit code on this machine. Just need to install all the required 32 bit libraries. Something like:

    $ dpkg --add-architecture i386
    Nono, don't do that. Debian 64-bit Linux is a full 32/64 bit operating system, 32-bit executables and 64-bit executables are equally valued citizens. You do _not_ want to install 32-bit libs for 32-bit Linux, you want 32-bit libs for 64-bit Linux.
    On Debian you simply do:
    $ apt-get install ia32-libs
    $ apt-get install ia32-libs-gtk
    (as bst is a gtk application I believe)
    These two should resolve everything needed for 32-bit executables. I have lots, including bst which I have been using from day one (of my Propeller activities) on my Debian 64-bit system.

    To elaborate, Linux, AIX and IRIX in their 64-bit variants are all 32/64-bit systems and can handle both equally well. The 32-bit support is integrated, so libraries from an actual 32-bit system aren't usually welcome. On Debian you'll find the 32-bit libs in /lib32/ and /usr/lib32/, just as on IRIX (on IRIX there's also /lib64/ and /usr/lib64/ because it actually supports 3 variants, an additional old 32-bit variant living in /lib and /usr/lib/)

    -Tor
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 05:13
    Tor,

    Excellent, thank you. That has opened my eyes a little about how 32bit support works in Debian. According to these pages you are right:
    http://packages.debian.org/fi/wheezy/ia32-libs
    http://packages.debian.org/fi/wheezy/ia32-libs-gtk

    Only trouble is it does not work! BST puts up a blank splash screen and then hangs.

    Here is what I did: 
    $ dpkg --add-architecture i386            # As suggested in the links above.
$ apt-get install  ia32-libs
$ apt-get install ia32-libs-gtk
    Now we see that bst has all it's expected libs in place:
    $ ldd bst.linux
        linux-gate.so.1 =>  (0xf7745000)
        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf7711000)
        libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf770d000)
        etc, etc, etc...
    Still, it does not work. No error messages to the console. Nothing but an empty splash box.

    I might dispute one detail though. Whilst doing all this I see that apt-get installs a whole bunch of 32 bit libs like ia32-libs-gtk-i386_1%3a0.1_i386.deb which do seem to be the normal 32bit Debian packages. One do can a similar job manually by doing: 
    $ apt-get install gtk2-engines-pixbuf:i386
    For the libs you want, after doing the add architecture thing of course.
  • CrosswindsCrosswinds Posts: 182
    edited 2013-03-31 05:37
    Hello!

    have you checked your systemlogs from your log deamon?

    Sometimes ive noticed that there is mostly error messages relating directly to the GTK engine that shows up in the console. Meanwhile the program itself often sends error messages directly to the log deamon..
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 05:43
    No nothing in any logs.

    It's worse than that. BST is dead Jim.
  • CrosswindsCrosswinds Posts: 182
    edited 2013-03-31 05:52
    Sorry to hear that!

    It almost feels like it wouldnt be trouble with 32 vs 64 since it shows its splash? Could it be somekind of permission errors?
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 06:05
    It's worse than that. It puts up a grey box where the splash should be but never draws anything in it.

    I was just checking I have permissions to my serial ports. All seems OK. I have run out of ideas.
  • TorTor Posts: 2,010
    edited 2013-03-31 06:06
    Heater. wrote: »
    Here is what I did: 
    $ dpkg --add-architecture i386            # As suggested in the links above.
    I would advice that you don't do this. I have only amd64. This is meant for when you want to install packages built for a 32-bit system, i.e. an alien package. BST isn't a Debian package, at least I've never seen one, I just got an executable (in case someone actually built a Debian i386 package from that it's easy to unpack and make a new Debian amd64 package from that. That is much better than using add-architecture. I would do dpkg --remove-architecture i386 now. Check with --print-architecture to verify that you have only amd64).
    $ apt-get install  ia32-libs
$ apt-get install ia32-libs-gtk
    Now we see that bst has all it's expected libs in place:
    $ ldd bst.linux
        linux-gate.so.1 =>  (0xf7745000)
        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf7711000)
        libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf770d000)
        etc, etc, etc...
    I don't know why you see the above. I see only this: 
    ldd `which bst`
        linux-gate.so.1 =>  (0xf77bd000)
        libdl.so.2 => /lib32/libdl.so.2 (0xf778c000)
        libX11.so.6 => /usr/lib32/libX11.so.6 (0xf766f000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib32/libgdk_pixbuf-2.0.so.0 (0xf7656000)
        libgtk-x11-2.0.so.0 => /usr/lib32/libgtk-x11-2.0.so.0 (0xf7280000)
    and so on. All libs live in /usr/lib32/
    Still, it does not work. No error messages to the console. Nothing but an empty splash box.
    I seem to remember something about access to /dev/ttyUSB0 or something, but it's been so long since I first installed bst that I don't remember at the moment. Can you start it as root?
    As said above, I really don't think adding an architecture is a good idea. It just messes up things. It's a method to make it possible to install alien packages without having to do --force-install all the time.

    -Tor
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 06:40
    Tor,

    No can do:
    $ dpkg --remove-architecture i386
dpkg: error: cannot remove architecture 'i386' currently in use by the database

    Looks like if it is buggered it is going to stay buggered:(

    Anyway, do bare in mind that this is Wheezy. When I read the package description for ia32-libs and ia32-libs-gtk it says:
    Transitional package to migrate ia32-libs to multiarch
    This is a transitional package used to migrate the ia32-libs package to true multiarch. It can be removed once nothing on the system depends on it.

    This package requires multiarch to be enabled before it can be installed, use "dpkg --add-architecture i386".

    That last line is not there for the Squeeze descriptions. That inclines me to think I did the right thing.

    My serial port permissions check out OK.
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 06:43
    When I do "ldd bst.linux" I get, for example this:

    libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 (0xf7171000)

    Which just happens to look mostly like yours except the directory is different.
  • TorTor Posts: 2,010
    edited 2013-03-31 07:05
    Heater. wrote: »
    When I do "ldd bst.linux" I get, for example this:

    libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 (0xf7171000)
    The above is a file from an i386 package, it looks like you have installed libgtk2.0-0 for i386. I suggest you dpkg --purge that one, followed by apt-get install --reinstall ia32-libs-gtk (you really want the version from there, as /usr/lib32/libgtk-x11-2.0.so.0). That may be enough that you can do dpkg --remove-architecture i386
    The only 'i386' I have installed is libc6-i386 (and libc6-dev-i386), but these are amd64-architecture packages, not i386: 
    ii  libc6-dev-i386   2.13-37    amd64  Embedded GNU C Library: 32-bit development libraries for AMD64
ii  libc6-i386         2.13-37    amd64  Embedded GNU C Library: 32-bit shared libraries for AMD64

    Edit: /usr/lib/i386/ should really be empty on 64-bit Debian Wheezy, use dpkg -S /usr/i386/name-of-each-file to figure out the package and remove it/them.

    -Tor
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2013-03-31 07:08
    I use BST all the time but mostly under Linux Mint. I think sometimes when I have installed a different distro that I have had to manually install the ia32 libs but otherwise all seems to work with Mint. If I didn't have BST and it's listing I might not have been able to produce Tachyon the way I did, I know being able to see what the compiler was doing allowed me to go back and make adjustments.

    Bring back BST I say but in saying that I know that Brad was more than cheesed off by the raw deal he was offered. I really don't know the politics but it's a real pity that a quality package like BST has been left to expire on the shelf. Is there any chance at all that this project can be revived?

    BTW, I've just simply run BST from the terminal when I've had problems so I can see any compatibility warnings and errors immediately/
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 07:12
    Everything I'm reading tells me I have done this right. For example here: http://wiki.debian.org/Multiarch/HOWTO and the Wheezy ia64 release notes.

    It did occur to be to uninstall all that 32 bit stuff and start again. But how? The full output of ldd is:
    # ldd bst.linux 
        linux-gate.so.1 =>  (0xf7733000)
        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf76ff000)
        libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf76fb000)
        libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf75c2000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xf75a0000)
        libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 (0xf712d000)
        libgdk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 (0xf707c000)
        libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xf702a000)
        libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xf6f2c000)
        libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xf6f29000)
        libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xf6f24000)
        libpango-1.0.so.0 => /usr/lib/i386-linux-gnu/libpango-1.0.so.0 (0xf6ed8000)
        libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xf6eb6000)
        libcairo.so.2 => /usr/lib/i386-linux-gnu/libcairo.so.2 (0xf6da7000)
        libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf6c44000)
        /lib/ld-linux.so.2 (0xf7734000)
        libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6c21000)
        librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf6c18000)
        libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xf6ab8000)
        libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xf6a8d000)
        libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf6a67000)
        libpangocairo-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xf6a5a000)
        libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 (0xf6a57000)
        libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xf6a54000)
        libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xf6a4d000)
        libpangoft2-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xf6a1f000)
        libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xf6983000)
        libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xf694d000)
        libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf693b000)
        libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xf6931000)
        libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 (0xf692e000)
        libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xf691f000)
        libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xf6917000)
        libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xf690d000)
        libffi.so.5 => /usr/lib/i386-linux-gnu/libffi.so.5 (0xf6903000)
        libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xf68c5000)
        libpixman-1.so.0 => /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xf682e000)
        libxcb-shm.so.0 => /usr/lib/i386-linux-gnu/libxcb-shm.so.0 (0xf682a000)
        libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 (0xf681f000)
        libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf6805000)
        libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6802000)
        libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf67fc000)
        libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xf67dc000)
        libresolv.so.2 => /lib/i386-linux-gnu/i686/cmov/libresolv.so.2 (0xf67c8000)
        libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf679d000)
    And that is only a fraction of what got installed with: 
    $ apt-get install  ia32-libs 
$ apt-get install ia32-libs-gtk

    How would I go about finding all the packages that operation installed and removing them?
  • TorTor Posts: 2,010
    edited 2013-03-31 07:27
    Heater. wrote: »
    Everything I'm reading tells me I have done this right. For example here: http://wiki.debian.org/Multiarch/HOWTO and the Wheezy ia64 release notes.
    Multiarch is the source of the problem.. you have done everything right to install (as it says on the page): 'install library packages from multiple architectures on the same machine.'
    But multiarch is not the same as the 32/64-bit ability of Linux I was talking about.. it's something entirely different really. It's for the sole purpose of being able to install alien packages. But you don't need that to run 32-bit applications on 64-bit Linux. Either the amd64 package for your system will actually have a 32-bit executable (there are some of those), or it's a stand-alone executable which is not packaged for Debian (e.g. 'bst'). In both of these cases multiarch is not needed and not wanted.
    It did occur to be to uninstall all that 32 bit stuff and start again. But how?[..]
    Untested, but.. 
    dpkg -S `find /usr/lib/i386-linux-gnu/ -type f -print`|sort|cut -d":" -f1 |uniq >list
dpkg --purge `cat list`
    (Your system is quite fresh, right? So you can afford braking it.. :)

    -Tor
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 07:41
    Tor,
    (Your system is quite fresh, right? So you can afford braking it..
    Oh yeah, very fresh. It's only on day three of getting everything installed and set up the way I like it !!!

    Are we reading the same documents? The multi-arch document says:
    What is this Multiarch?

    Multiarch lets you install library packages from multiple architectures on the same machine. This is useful in various ways, but the most common is installing both 64 and 32-bit software on the same machine and having dependencies correctly resolved automatically. In general you can have libraries of more than one architecture installed together and applications from one architecure or another installed as alternatives. Note that it does not enable multiple architecture versions of applications to be installed simultaneously.

    Bold emphasis above by me. Looks like exactly what I want.

    The list produced by your first command above gives package names with no reference to architecture, so I could end up purging all the normal 64 bit library packages !!!! I think I need the ":i386" in the somewhere.
  • TorTor Posts: 2,010
    edited 2013-03-31 07:53
    (Sorry for not quoting exactly what I'm replying to, but I have to format the message manually as I mentioned in another post, so it's quite a lot of work)
    That's what the multi-arch document says, but what I say is still true: Multi-archi is for when you really need to install i386 packages (.deb packages with i386 in the architecture part of the name) on an amd64 machine. This is really the exception. I have tons of software on the machine and I have never needed actual i386 packages to run 32-bit software. That is what the ia32 libs packages are for.

    It's true (as you have figured out) that the command would not be able to differentiate between amd64 and i386 packages, sorry about that - my system is empty in /usr/lib/i386* so I couldn't test it properly.
    Maybe it's simply easier to do 
    dpkg -l | grep i386|grep -v -i amd64
    and (after some massaging) dpkg --purge the output of that.

    (and then dpkg --remove-architecture i386 to prevent i386 packages to be installed again)

    -Tor
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 08:12
    I'm still not convinced:)

    I follow you as far as when you say "That is what the ia32 libs packages are for". But then, when I look at the Wheezy description of the ia32-libs package it specifically says:
    "This package requires multiarch to be enabled before it can be installed, use "dpkg --add-architecture i386".
    Which it does not for Squeeze. Same for ia32-libs-gtk in Wheezy.

    In the mean time I tried an experiment. I down loaded a 32 bit Qt program that I have built on Squeeze. It uses Qt libs but not anything graphical.
    Anyway the output from ldd for this program tells a similar story:
    # ldd lstream_server
    linux-gate.so.1 => (0xf779b000)
    libQtXml.so.4 => /usr/lib/i386-linux-gnu/libQtXml.so.4 (0xf773e000)
    libQtNetwork.so.4 => /usr/lib/i386-linux-gnu/libQtNetwork.so.4 (0xf75fb000)
    libQtCore.so.4 => /usr/lib/i386-linux-gnu/libQtCore.so.4 (0xf7314000)
    libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf72fb000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf720f000)
    libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf71e9000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf71cc000)
    libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf7068000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf704f000)
    libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf704b000)
    librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf7042000)
    libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xf6f45000)
    /lib/ld-linux.so.2 (0xf779c000)
    libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xf6f06000)

    Lo and behold this program runs just fine!!!

    My conclusion is that my 32 bit lib support was installed correctly.

    Still, as BST does not work I'm still open to being wrong:)
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 08:39
    OK. I just compiled a Qt graphical program on a remote 32 bit Squeeze machine. Just a window and a button.
    I down loaded the executable to this 64 bit machine and it has the familiar ldd dependencies like we have seen above.

    It runs fine.

    I think my 32 bit libs are installed correctly. The problem with BST is deeper. Or at least something else.
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 08:52
    Further to the story. The 32 bit version of SimpleIDE works fine here as well:
    $ file  SimpleIDE 
SimpleIDE: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x745fb68eb893709de16a05f8b6515e871e6f1321, not stripped
$ ldd  SimpleIDE 
        linux-gate.so.1 =>  (0xf7742000)
        libQtGui.so.4 => /usr/lib/i386-linux-gnu/libQtGui.so.4 (0xf6c43000)
        libQtCore.so.4 => /usr/lib/i386-linux-gnu/libQtCore.so.4 (0xf695d000)
        libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xf6943000)
        libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf6857000)
        libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf6831000)
        libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf6814000)
        libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf66b1000)
        libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xf667a000)
        libaudio.so.2 => /usr/lib/i386-linux-gnu/libaudio.so.2 (0xf6660000)
        libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xf6563000)
        libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xf6539000)
        libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf6520000)
        libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xf6483000)
        libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xf6431000)
        libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0xf6429000)
        libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0xf6410000)
        libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xf6407000)
        libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf63f4000)
        libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf62bc000)
        libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf62b8000)
        librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xf62af000)
        /lib/ld-linux.so.2 (0xf7743000)
        libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf6285000)
        libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0xf6226000)
        libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6223000)
        libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xf61e5000)
        libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xf61e2000)
        libffi.so.5 => /usr/lib/i386-linux-gnu/libffi.so.5 (0xf61d9000)
        libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf61d2000)
        libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf61af000)
        libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf61a9000)

    Something is up with my 32 bit GTK libs I bet.
  • Heater.Heater. Posts: 21,230
    edited 2013-03-31 09:22
    Hurrah, yipee, bingo!!!

    I have been trying to run the last pre-release snapshot of BST, bst-0.19.4-pre14, it does not work.

    BUT the last release version bst-0.19.3 works fine !!!

    Now all I have to do is work backwards and find out at which version it stops working.

    Edit: I did not have to go back far. bst-0.19.4-pre12 works fine. Things break for pre13.
  • Wilt VineWilt Vine Posts: 6
    edited 2013-03-31 16:34
    Peter Jakacki wrote: »
    Brad was more than cheesed off by the raw deal he was offered.
    Eh? Parallax didn't want to shell out the $?
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-04-01 04:47
    Brad is fine but off doing other things, and does not frequent the forums at all now. BST was written in Pascal by him without any help or code from what I understand.
    It is such a shame considering how well bst ran across all platforms, and gave us listings and conditional compilation. Thanks again Brad - there are so many things we could not have developed without your work.
  • richaj45richaj45 Posts: 179
    edited 2013-04-01 08:05
    Cluso99:

    Do you know which version of Pascal and is Brad willing to let other people take over work on his program?

    cheers,
    rich
  • David BetzDavid Betz Posts: 14,516
    edited 2013-04-01 08:51
    richaj45 wrote: »
    Cluso99:

    Do you know which version of Pascal and is Brad willing to let other people take over work on his program?

    cheers,
    rich
    I think many people have tried to get Brad to release the sources including Parallax and he doesn't seem willing. I suppose things may have changed but I think it's probably a long shot.
  • ersmithersmith Posts: 6,054
    edited 2013-04-01 09:00
    Perhaps it would make sense to improve the open source spin compiler so that it has the features of bst that it is currently missing. It does have a simple preprocessor, so it should be able to compile anything you were compiling with bstc, but I don't know if it has listing files or the optimizations that bstc has.

    Eric
  • KC_RobKC_Rob Posts: 465
    edited 2013-04-01 11:08
    Peter Jakacki wrote: »
    Bring back BST I say but in saying that I know that Brad was more than cheesed off by the raw deal he was offered. I really don't know the politics but it's a real pity that a quality package like BST has been left to expire on the shelf. Is there any chance at all that this project can be revived?
    I only know about this from what I've read here, but it does seem a pity to let a perfectly good and useful tool like BST needlessly die. (Unless, perchance, work is underway to replace it with something even better??)
  • Heater.Heater. Posts: 21,230
    edited 2013-04-01 11:41
    Eric,

    I thought it was obvious. Many of us out here need the features of BSTC. The optimizations, the dead code removal, the #ifdef, the list files etc etc

    Many of us have been relying on that stuff for years now.

    The open source spin compiler has to move on from just doing what the Spin Tool does.
Sign In or Register to comment.