Recommendation for Virtual Machine and Instructions to set it up?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Recommendation for Virtual Machine and Instructions to set it up?

rhkramer
Background:

I'm involved with having some software written and then testing it.

The software won't run on either my Wheezy or Jessie systems -- it appears to
be an outdated libstdc++ that is the problem.

We've tried a few different solutions, including trying to install updated
libstdc++ library using dpkg -i and having the package compiled statically
(although, for some reason, the programmer couldn't get it completed static,
it apparently still needs some share libraries).

Getting to the question:

I suppose I could as some more questions related to that, but, for now, the
next suggestion (aside from upgrading one of my machines to stretch (or
whatever the current stable is) is to do something like create a virtual
machine and install Ubuntu on it (because the programmer also uses Ubuntu and
it works there for him) -- I suppose I might also (eventually) try stretch on
the VM.

I think I'd install the VM on my Jessie machine, as there is less data at risk
there (and, of course, I need to backup that data before proceeding), but the
question is:

Question:

What would you recommend for the software to run a VM under Jessie (that would
probably run Ubuntu), and can you recommend a fairly simple set of
instructions to first set up the VM, and then at least begin the install
process to that VM.

Thanks!

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

Tom Browder
On Thu, Dec 6, 2018 at 10:12 AM <[hidden email]> wrote:
>
> Background:
>
> I'm involved with having some software written and then testing it.
>
> The software won't run on either my Wheezy or Jessie systems -- it appears to
> be an outdated libstdc++ that is the problem.

Before I go the VM route, I would try installing the latest clang or
gcc on the host you use normally. Rather than chasing OS's, you need
to get that software more portable IMHO.

Best regards,

-Tom

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

Roberto C. Sánchez-2
In reply to this post by rhkramer
On Thu, Dec 06, 2018 at 11:11:56AM -0500, [hidden email] wrote:
> Background:
>
> I'm involved with having some software written and then testing it.
>
> The software won't run on either my Wheezy or Jessie systems -- it appears to
> be an outdated libstdc++ that is the problem.
>
That seems to be rather peculiar.  Is the software also built on the
wheezy or jessie system before attempting to run it, or is it built
elsewhere?  What is the exact error output that you get?  What is the
output of 'ldd /path/to/the/program'?  Is it written in C++?

> We've tried a few different solutions, including trying to install updated
> libstdc++ library using dpkg -i

Wow.  That is just asking for trouble.  I strongly recommend against
that.

> and having the package compiled statically
> (although, for some reason, the programmer couldn't get it completed static,
> it apparently still needs some share libraries).
>
That is not especially surprising.  I have just today encountered an
open source project that I need to build from source that fails to build
if I try to static link it.

> Getting to the question:
>
> I suppose I could as some more questions related to that, but, for now, the
> next suggestion (aside from upgrading one of my machines to stretch (or
> whatever the current stable is) is to do something like create a virtual
> machine and install Ubuntu on it (because the programmer also uses Ubuntu and
> it works there for him) -- I suppose I might also (eventually) try stretch on
> the VM.
>
> I think I'd install the VM on my Jessie machine, as there is less data at risk
> there (and, of course, I need to backup that data before proceeding), but the
> question is:
>
> Question:
>
> What would you recommend for the software to run a VM under Jessie (that would
> probably run Ubuntu), and can you recommend a fairly simple set of
> instructions to first set up the VM, and then at least begin the install
> process to that VM.
>
It seems like a chroot environment might be less work.  Without knowing
precisely what resources the software needs, though I cannot be certain
if it is suitable.  In any event, building a chroot environment is as
simple as installing debootstrap and then doing this:

sudo debootstrap unstable /path/to/chroot

After that, you can install your program under that directory and run it
with:

sudo chroot /path/to/chroot /inside/chroot/path/program

Or, so work interactively in the chroot:

sudo chroot /path/to/chroot /bin/bash

The debootstrap utility knows about the Debian releases as well as the
Ubuntu releases and should be able to set up either.  Though, you may
need to install an updated debootstrap for setting up chroots for the
latest Debian or Ubuntu releases.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

deloptes-2
In reply to this post by rhkramer
[hidden email] wrote:

> What would you recommend for the software to run a VM under Jessie (that
> would probably run Ubuntu), and can you recommend a fairly simple set of
> instructions to first set up the VM, and then at least begin the install
> process to that VM.

Recently I am using headless or sometimes visual virtualbox. If you want it
headless virtualbox is better. There are packages to download. I don't know
if and which work on jessie.
I do not think you need a backup if you install the packages. If it
installes well, you do not risk anything as the VM you create is isolated
from the OS. You will need a netinstall iso image to create the OS. It
works also straight forward.

There are good howtos around. I saw the suggestion to use chroot, which is
cheaper, but it might be that you get only older versions of ubuntu and
debian.

regards

Reply | Threaded
Open this post in threaded view
|

Fwd: Recommendation for Virtual Machine and Instructions to set it up?

Mark Fletcher-2
Darn it, forgot to monkey with the headers when replying from gmail... please see intended list reply below. 

---------- Forwarded message ---------
From: Mark Fletcher <[hidden email]>
Date: Fri, Dec 7, 2018 at 8:19
Subject: Re: Recommendation for Virtual Machine and Instructions to set it up?
To: <[hidden email]>




On Fri, Dec 7, 2018 at 6:03 deloptes <[hidden email]> wrote:
[hidden email] wrote:

> What would you recommend for the software to run a VM under Jessie (that
> would probably run Ubuntu), and can you recommend a fairly simple set of
> instructions to first set up the VM, and then at least begin the install
> process to that VM.

Recently I am using headless or sometimes visual virtualbox. If you want it
headless virtualbox is better. There are packages to download. I don't know
if and which work on jessie.
I do not think you need a backup if you install the packages.


I second this. I’ve been using virtualbox since around etch or so I think — anyway a while. Since you’re on Jessie it should be in the repos. From stretch on you need to add a repo to get it as it fell out if the Debian repo. But it is still in Jessie — at least it was when Jessie was stable. 

I have always found virtualbox surprisingly easy to set up and use — a lot of things that as a noob I expected to be hard just weren’t. There’s a good visual setup screen for creating new VMs and the documentation is quite good as I recall. 

The only thing I’ve never got working properly is 3D acceleration. 

HTH 

Mark
Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

rhkramer
In reply to this post by Tom Browder
On Thursday, December 06, 2018 12:39:22 PM Tom Browder wrote:

> On Thu, Dec 6, 2018 at 10:12 AM <[hidden email]> wrote:
> > Background:
> >
> > I'm involved with having some software written and then testing it.
> >
> > The software won't run on either my Wheezy or Jessie systems -- it
> > appears to be an outdated libstdc++ that is the problem.
>
> Before I go the VM route, I would try installing the latest clang or
> gcc on the host you use normally. Rather than chasing OS's, you need
> to get that software more portable IMHO.

Thanks for the response!  Unfortunately:

   1) I am not good at compiling software -- the programmer I'm working with
created a binary for me to test
   2) The underlying software which is being modified uses C++17 features -- I
don't think I can get that for Wheezy or Jessie

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

rhkramer
In reply to this post by Roberto C. Sánchez-2
On Thursday, December 06, 2018 12:59:19 PM Roberto C. Sánchez wrote:

> On Thu, Dec 06, 2018 at 11:11:56AM -0500, [hidden email] wrote:
> > Background:
> >
> > I'm involved with having some software written and then testing it.
> >
> > The software won't run on either my Wheezy or Jessie systems -- it
> > appears to be an outdated libstdc++ that is the problem.
>
> That seems to be rather peculiar.  Is the software also built on the
> wheezy or jessie system

Nope -- the software was compiled (into a binary) on a Ubuntu system which
apparently can compile C++17

> before attempting to run it, or is it built
> elsewhere?  

Elsewhere

> What is the exact error output that you get?

On Wheezy:

rhk@s19:/rhk/downloads2/Scintilla_Dusan$ SciTE
SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not
found (required by SciTE)
SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.19' not
found (required by SciTE)
SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not
found (required by SciTE)
SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not
found (required by SciTE)
SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not
found (required by SciTE)
rhk@s19:/rhk/downloads2/Scintilla_Dusan$

On Jessie, very similar but only mentions two versions not found:  
`CXXABI_1.3.9' and `GLIBCXX_3.4.21'

> What is the
> output of 'ldd /path/to/the/program'?  

On Wheezy (Wheezy is easier for me to send emails to / from):

<quote>
rhk@s19:/rhk/downloads2/Scintilla_Dusan$ ldd /usr/local/bin/SciTE
/usr/local/bin/SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`CXXABI_1.3.8' not found (required by /usr/local/bin/SciTE)
/usr/local/bin/SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.19' not found (required by /usr/local/bin/SciTE)
/usr/local/bin/SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`CXXABI_1.3.9' not found (required by /usr/local/bin/SciTE)
/usr/local/bin/SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.21' not found (required by /usr/local/bin/SciTE)
/usr/local/bin/SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.20' not found (required by /usr/local/bin/SciTE)
        linux-vdso.so.1 =>  (0x00007ffc32575000)
        libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
(0x00007f155fdde000)
        libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
(0x00007f155fb2b000)
        libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-
gnu/libpangocairo-1.0.so.0 (0x00007f155f91e000)
        libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0
(0x00007f155f6fb000)
        libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
(0x00007f155f401000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-
gnu/libgdk_pixbuf-2.0.so.0 (0x00007f155f1e1000)
        libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
(0x00007f155ef94000)
        libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(0x00007f155ed44000)
        libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
(0x00007f155eb40000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x00007f155e848000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f155e541000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f155e2bf000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f155e0a9000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f155de8d000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f155db00000)
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x00007f155d7c5000)
        libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1
(0x00007f155d5c3000)
        libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
(0x00007f155d3c1000)
        libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
(0x00007f155d1bb000)
        libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x00007f155ce68000)
        libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
(0x00007f155cc3d000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x00007f155c99e000)
        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
(0x00007f155c767000)
        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x00007f155c555000)
        libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x00007f155c34b000)
        libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1
(0x00007f155c149000)
        libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6
(0x00007f155bf3a000)
        libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2
(0x00007f155bd32000)
        libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1
(0x00007f155bb28000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f155b920000)
        libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
(0x00007f155b69a000)
        libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x00007f155b473000)
        libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
(0x00007f155b270000)
        libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
(0x00007f155b066000)
        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x00007f155ae46000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f155ac2f000)
        libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0
(0x00007f155aa2d000)
        libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5 (0x00007f155a820000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f155a61c000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3
(0x00007f155a3df000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f15608d1000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x00007f155a1bf000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x00007f1559fa9000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
(0x00007f1559d7f000)
        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x00007f1559b7c000)
        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007f1559977000)

</quote>

> Is it written in C++?

Yes.

>
> > We've tried a few different solutions, including trying to install
> > updated libstdc++ library using dpkg -i
>
> Wow.  That is just asking for trouble.  I strongly recommend against
> that.
>
> > and having the package compiled statically
> > (although, for some reason, the programmer couldn't get it completed
> > static, it apparently still needs some share libraries).
>
> That is not especially surprising.  I have just today encountered an
> open source project that I need to build from source that fails to build
> if I try to static link it.

Any idea why -- that was very disappointing, in fact, compiling it static
added only about 450 bytes to the zip file containing the executable (and
related stuff -- a .pdf and a bunch of property files and such).

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

Roberto C. Sánchez-2
On Thu, Dec 06, 2018 at 08:01:31PM -0500, [hidden email] wrote:

> On Thursday, December 06, 2018 12:59:19 PM Roberto C. Sánchez wrote:
> > On Thu, Dec 06, 2018 at 11:11:56AM -0500, [hidden email] wrote:
> > > Background:
> > >
> > > I'm involved with having some software written and then testing it.
> > >
> > > The software won't run on either my Wheezy or Jessie systems -- it
> > > appears to be an outdated libstdc++ that is the problem.
> >
> > That seems to be rather peculiar.  Is the software also built on the
> > wheezy or jessie system
>
> Nope -- the software was compiled (into a binary) on a Ubuntu system which
> apparently can compile C++17
>

I suspect your programmer may not fully understand what he or she is
doing.

I created a sid chroot, then did the following:

apt install -y build-essential less vim libgtk2.0-dev mercurial
hg clone http://hg.code.sf.net/p/scintilla/code scintilla
hg clone http://hg.code.sf.net/p/scintilla/scite scintilla-scite
cd scintilla/gtk/
make
cd ../../scintilla-scite/gtk/
make

After that, I copied scintilla-scite/bin/SciTE into the root directory
(/) in a wheezy and a jessie chroot.  Here is what I got from the wheezy
chroot:

sudo chroot ./wheezy-chroot/ ./SciTE
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./SciTE)
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./SciTE)
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./SciTE)
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./SciTE)
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./SciTE)

>From jessie:

sudo chroot ./jessie-chroot/ ./SciTE
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./SciTE)
./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./SciTE)

So, those would be the libstdc++ problem.  I then made this change in
scintilla-scite:

diff -r 6e7614763bad gtk/makefile
--- a/gtk/makefile      Tue Dec 04 08:45:32 2018 +1100
+++ b/gtk/makefile      Fri Dec 07 02:38:46 2018 +0000
@@ -126,7 +126,7 @@
 MatchMarker.o StringHelpers.o \
 PropSetFile.o MultiplexExtension.o DirectorExtension.o SciTEProps.o StyleDefinition.o StyleWriter.o Utf8_16.o \
        JobQueue.o GTKMutex.o IFaceTable.o $(COMPLIB) $(LUA_OBJS)
-       $(CXX) `$(CONFIGTHREADS)` -rdynamic -Wl,--as-needed -Wl,--version-script $(srcdir)/lua.vers -DGTK $^ -o $@ $(CONFIGLIB) $(LIBDL) $(LDLIBS) -lm -lstdc++
+       $(CXX) `$(CONFIGTHREADS)` -rdynamic -Wl,--as-needed -Wl,--version-script $(srcdir)/lua.vers -DGTK $^ -o $@ $(CONFIGLIB) $(LIBDL) $(LDLIBS) -lm -static-libstdc++
 
 # Automatically generate header dependencies with "make deps"
 include deps.mak

As you can see, I swapped '-lstdc++' for '-static-libstdc++'.

Then I removed scintilla-scite/bin/SciTE and ran make again in
scintilla-scite/gtk and copied the new scintilla-scite/bin/SciTE into
the same wheezy and jessie chroots.

Now, in wheezy I get this:

sudo chroot ./wheezy-chroot/ ./SciTE
./SciTE: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by ./SciTE)
./SciTE: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./SciTE)

That makes sense since the glibc in wheezy is version 2.13.  However,
when I ran it in jessie, the editor window appeared.

All of this took roughly 45 minutes for me to diagnose, with most of
that time spent waiting on packages to download over my slow connection
to set up the chroots.

Let me know if you have any questions.

Regards,

-Roberto
--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

rhkramer
On Thursday, December 06, 2018 10:11:44 PM Roberto C. Sánchez wrote:

> On Thu, Dec 06, 2018 at 08:01:31PM -0500, [hidden email] wrote:
> > On Thursday, December 06, 2018 12:59:19 PM Roberto C. Sánchez wrote:
> > > On Thu, Dec 06, 2018 at 11:11:56AM -0500, [hidden email] wrote:
> > > > Background:
> > > >
> > > > I'm involved with having some software written and then testing it.
> > > >
> > > > The software won't run on either my Wheezy or Jessie systems -- it
> > > > appears to be an outdated libstdc++ that is the problem.
> > >
> > > That seems to be rather peculiar.  Is the software also built on the
> > > wheezy or jessie system
> >
> > Nope -- the software was compiled (into a binary) on a Ubuntu system
> > which apparently can compile C++17
>
> I suspect your programmer may not fully understand what he or she is
> doing.

Thanks for the reply and your efforts!

I'll probably try some of this starting tomorrow afternoon, but, just for the
record, the programmer did fine -- he modified the program and got it working on
his Ubuntu system, and created a binary for me.  The problem now is to get the
binary to work on my Wheezy or Jessie system.

Of course, looking at what you did, maybe I should get the source of his
changes and then try compiling it myself (in a sid chroot).  I guess the C++
in sid is C++17?  (I'm not sure how much code in scite / scintilla actually
uses C++17 features, nor if the lexer he is writing for me uses C++17
features.)

>
> I created a sid chroot, then did the following:
>
> apt install -y build-essential less vim libgtk2.0-dev mercurial
> hg clone http://hg.code.sf.net/p/scintilla/code scintilla
> hg clone http://hg.code.sf.net/p/scintilla/scite scintilla-scite
> cd scintilla/gtk/
> make
> cd ../../scintilla-scite/gtk/
> make
>
> After that, I copied scintilla-scite/bin/SciTE into the root directory
> (/) in a wheezy and a jessie chroot.  Here is what I got from the wheezy
> chroot:
>
> sudo chroot ./wheezy-chroot/ ./SciTE
> ./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8'
> not found (required by ./SciTE) ./SciTE:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.19' not
> found (required by ./SciTE) ./SciTE:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found
> (required by ./SciTE) ./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6:
> version `GLIBCXX_3.4.21' not found (required by ./SciTE) ./SciTE:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not
> found (required by ./SciTE)
>
> >From jessie:
> sudo chroot ./jessie-chroot/ ./SciTE
> ./SciTE: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9'
> not found (required by ./SciTE) ./SciTE:
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not
> found (required by ./SciTE)
>
> So, those would be the libstdc++ problem.  I then made this change in
> scintilla-scite:
>
> diff -r 6e7614763bad gtk/makefile
> --- a/gtk/makefile      Tue Dec 04 08:45:32 2018 +1100
> +++ b/gtk/makefile      Fri Dec 07 02:38:46 2018 +0000
> @@ -126,7 +126,7 @@
>  MatchMarker.o StringHelpers.o \
>  PropSetFile.o MultiplexExtension.o DirectorExtension.o SciTEProps.o
> StyleDefinition.o StyleWriter.o Utf8_16.o \ JobQueue.o GTKMutex.o
> IFaceTable.o $(COMPLIB) $(LUA_OBJS)
> -       $(CXX) `$(CONFIGTHREADS)` -rdynamic -Wl,--as-needed
> -Wl,--version-script $(srcdir)/lua.vers -DGTK $^ -o $@ $(CONFIGLIB)
> $(LIBDL) $(LDLIBS) -lm -lstdc++ +       $(CXX) `$(CONFIGTHREADS)`
> -rdynamic -Wl,--as-needed -Wl,--version-script $(srcdir)/lua.vers -DGTK $^
> -o $@ $(CONFIGLIB) $(LIBDL) $(LDLIBS) -lm -static-libstdc++
>
>  # Automatically generate header dependencies with "make deps"
>  include deps.mak
>
> As you can see, I swapped '-lstdc++' for '-static-libstdc++'.
>
> Then I removed scintilla-scite/bin/SciTE and ran make again in
> scintilla-scite/gtk and copied the new scintilla-scite/bin/SciTE into
> the same wheezy and jessie chroots.
>
> Now, in wheezy I get this:
>
> sudo chroot ./wheezy-chroot/ ./SciTE
> ./SciTE: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found
> (required by ./SciTE) ./SciTE: /lib/x86_64-linux-gnu/libc.so.6: version
> `GLIBC_2.14' not found (required by ./SciTE)
>
> That makes sense since the glibc in wheezy is version 2.13.  However,
> when I ran it in jessie, the editor window appeared.
>
> All of this took roughly 45 minutes for me to diagnose, with most of
> that time spent waiting on packages to download over my slow connection
> to set up the chroots.
>
> Let me know if you have any questions.
>
> Regards,
>
> -Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

Roberto C. Sánchez-2
On Thu, Dec 06, 2018 at 10:37:51PM -0500, [hidden email] wrote:

>
> I'll probably try some of this starting tomorrow afternoon, but, just for the
> record, the programmer did fine -- he modified the program and got it working on
> his Ubuntu system, and created a binary for me.  The problem now is to get the
> binary to work on my Wheezy or Jessie system.
>
> Of course, looking at what you did, maybe I should get the source of his
> changes and then try compiling it myself (in a sid chroot).  I guess the C++
> in sid is C++17?  (I'm not sure how much code in scite / scintilla actually
> uses C++17 features, nor if the lexer he is writing for me uses C++17
> features.)
>

No problem.

Perhaps I should have taken more care with my phrasing.  I am sure the
programmer here is doing a fine job.  In my experience, the weakest area
for nearly every programmer I meet is build systems.  Interestingly
enough, I lectured in class today and build systems and their
importance.  This is a case where understanding some of the "extras"
that many other programmers either overlook or do not have to deal with
is key to solving the problem.

As far as what you do next, it should be sufficient to have him swap
'-lstdc++' for '-static-libstdc++' and then rebuild.  That should get
you a working binary.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

andy smith-10
In reply to this post by rhkramer
Hi,

On Thu, Dec 06, 2018 at 10:37:51PM -0500, [hidden email] wrote:
> just for the record, the programmer did fine -- he modified the
> program and got it working on his Ubuntu system, and created a
> binary for me.  The problem now is to get the binary to work on my
> Wheezy or Jessie system.

It's not really reasonable to expect a binary built on a completely
different Linux distribution to run unchanged on your own machines.
I mean, it can be achieved, with some care, but is not the normal
way to do this.

You would be better off having your build and production
environments being the same. Ideally that could be achieved by both
your developer and you building/running the binary from a chroot of
the same thing, e.g. whatever version of Ubuntu the developer is
using. If the developer can't build this in a chroot then you could
just run it in a chroot that matches what the developer is building
it in.

If your developer hopes to be building software for use by multiple
people on Debian and Ubuntu, they would be well advised to look into
how to build proper Debian packages, using pbuilder or cowbuilder or
whatever, so they can distribute deb files for stable, oldstable
etc. without any of these concerns.

Or, your developer should deliver only portable source to you, and
you compile that yourself.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Recommendation for Virtual Machine and Instructions to set it up?

deloptes-2
In reply to this post by Mark Fletcher-2
Mark Fletcher wrote:


>
> I have always found virtualbox surprisingly easy to set up and use — a lot
> of things that as a noob I expected to be hard just weren’t. There’s a
> good visual setup screen for creating new VMs and the documentation is
> quite good as I recall.
>

The headless feature and option to manage from command line are of
advantage.

> The only thing I’ve never got working properly is 3D acceleration.

on the intel board glxgears says 4588 in 5.0 seconds = 917.401 FPS.

What do you mean by working properly?

regards





Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

Joe Rowan
In reply to this post by rhkramer
On Thu, 6 Dec 2018 22:37:51 -0500
[hidden email] wrote:


>
> Of course, looking at what you did, maybe I should get the source of
> his changes and then try compiling it myself (in a sid chroot).

If you're on sid, you may need to be a little more careful,
particularly with kernels. Years ago (it may be better now) I found
that the latest sid kernel was often not compatible with the sid
virtualbox kernel modules, they took a while to catch up. You may need
to hang on to older kernels for a while. The same kind of thing seemed
to apply to new sid kernels and the vb guest extras on Windows, if
you're doing sid-in-Windows.

--
Joe

Reply | Threaded
Open this post in threaded view
|

OT(?) question {Re: Recommendation for Virtual Machine and Instructions to set it up?}

Richard Owlett-3
In reply to this post by Roberto C. Sánchez-2
On 12/06/2018 09:42 PM, Roberto C. Sánchez wrote:
> [snip]  In my experience, the weakest area
> for nearly every programmer I meet is build systems.  Interestingly
> enough, I lectured in class today and build systems and their
> importance.  This is a case where understanding some of the "extras"
> that many other programmers either overlook or do not have to deal with
> is key to solving the problem.

I've been casually following this thread which has marginally touched on
various problems I encounter.

What is the title of your course and/or heading of the section you are
currently covering. I'm looking for key words for a web search.

I've minimal formal Comp Sci background but date back to 026 keypunch
and line printers being standard I/O. I find key word searches valuable
in tying together bits and pieces of decades of experience.

TIA




Reply | Threaded
Open this post in threaded view
|

Re: Recommendation for Virtual Machine and Instructions to set it up?

Roberto C. Sánchez-2
In reply to this post by andy smith-10
On Fri, Dec 07, 2018 at 07:12:29AM +0000, Andy Smith wrote:
>
> Or, your developer should deliver only portable source to you, and
> you compile that yourself.
>
Which he already said was not a workable solution, as he needs to run on
jessie and/or wheezy while the code in question requires a new enough
gcc to support c++17.

Regards,

-Roberto
--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Progress (was: Re: Recommendation for Virtual Machine and Instructions to set it up?)

rhkramer
In reply to this post by Roberto C. Sánchez-2
On Thursday, December 06, 2018 10:42:48 PM Roberto C. Sánchez wrote:
> As far as what you do next, it should be sufficient to have him swap
> '-lstdc++' for '-static-libstdc++' and then rebuild.  That should get
> you a working binary.

Thanks!

The programmer did what you suggested and that binary works for me on my
Jessie system.  Eventually I will try it on my Wheezy system.

I do plan to continue with some of the other suggestions made in this thread
(like the ones to create a chroot and then compile there, and then maybe to
play with some virtual machines).

My next step is to play with that executable and confirm that it performs as
expected.

As a side note (and with no good reason to post this here) -- back in the day
I used to do all kinds of things with computers (at least, the kinds of things
I needed to do for one reason or another, including things related to my job),
now I find that learning and trying new things is often a stressful experience
(which, among other things, leads to bad eating habits).

I need to learn to change that, somehow.

Reply | Threaded
Open this post in threaded view
|

Re: Progress (was: Re: Recommendation for Virtual Machine and Instructions to set it up?)

Roberto C. Sánchez-2
On Fri, Dec 07, 2018 at 01:47:44PM -0500, [hidden email] wrote:
> On Thursday, December 06, 2018 10:42:48 PM Roberto C. Sánchez wrote:
> > As far as what you do next, it should be sufficient to have him swap
> > '-lstdc++' for '-static-libstdc++' and then rebuild.  That should get
> > you a working binary.
>
> Thanks!
>
> The programmer did what you suggested and that binary works for me on my
> Jessie system.

That is excellent news.

> Eventually I will try it on my Wheezy system.
>

I would not expect that to work because of the outdated glibc.  You
would need to use a newer gcc on wheezy or take some other steps to
ensure that building on a newer system does not pull in newer glibc
symbols that do not exist on wheezy.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Progress (was: Re: Recommendation for Virtual Machine and Instructions to set it up?)

tomas@tuxteam.de
In reply to this post by rhkramer
On Fri, Dec 07, 2018 at 01:47:44PM -0500, [hidden email] wrote:

> On Thursday, December 06, 2018 10:42:48 PM Roberto C. Sánchez wrote:
> > As far as what you do next, it should be sufficient to have him swap
> > '-lstdc++' for '-static-libstdc++' and then rebuild.  That should get
> > you a working binary.
>
> Thanks!
>
> The programmer did what you suggested and that binary works for me on my
> Jessie system.  Eventually I will try it on my Wheezy system.
>
> I do plan to continue with some of the other suggestions made in this thread
> (like the ones to create a chroot and then compile there, and then maybe to
> play with some virtual machines).
[...]

Note that if the build is "just a chroot away" (meaning that you just need
other, possibly incopatible library versions, but not another kernel, for
example) schroot (a wrapper around chroot) or sbuild (a Debian package builder
in a chroot) might ease your work a bit.

Including cross-building of packages for different architectures, with the
help of QEMU.

Either your developer sets things up to deliver a binary (or a Debian package)
fit for your box or you test things (as you did now) things prepared for your
developer's box.

> now I find that learning and trying new things is often a stressful experience
> (which, among other things, leads to bad eating habits).

Accept that learning takes time. Loads of it.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Progress (was: Re: Recommendation for Virtual Machine and Instructions to set it up?)

rhkramer
In reply to this post by Roberto C. Sánchez-2
Hey, that's not fair -- you answered my question before I even asked it! ;-)  
But I included my findings below

On Friday, December 07, 2018 02:32:13 PM Roberto C. Sánchez wrote:

> On Fri, Dec 07, 2018 at 01:47:44PM -0500, [hidden email] wrote:
> > On Thursday, December 06, 2018 10:42:48 PM Roberto C. Sánchez wrote:
> > > As far as what you do next, it should be sufficient to have him swap
> > > '-lstdc++' for '-static-libstdc++' and then rebuild.  That should get
> > > you a working binary.
> >
> > Thanks!
> >
> > The programmer did what you suggested and that binary works for me on my
> > Jessie system.
>
> That is excellent news.
>
> > Eventually I will try it on my Wheezy system.
>
> I would not expect that to work because of the outdated glibc.  You
> would need to use a newer gcc on wheezy or take some other steps to
> ensure that building on a newer system does not pull in newer glibc
> symbols that do not exist on wheezy.

Ok, you're right, it doesn't work on Wheezy, but for now, I'm not worried
about that, I'll just do "testing" on my Jessie system.

The errors are slightly different (which is what you expected), this time I
see:

rhk@s19:/rhk/downloads2/Scintilla_Dusan$ SciTE
SciTE: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found
(required by SciTE)
SciTE: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found
(required by SciTE)

These missing symbols (iiuc) are different than the ones that were originally
missing -- originally the missing ones (on Wheezy) were:

`GLIBCXX_3.4.19'
`GLIBCXX_3.4.20'
`GLIBCXX_3.4.21'
`CXXABI_1.3.8'
`CXXABI_1.3.9'

regards,
Randy Kramer

Reply | Threaded
Open this post in threaded view
|

Re: Progress (was: Re: Recommendation for Virtual Machine and Instructions to set it up?)

Roberto C. Sánchez-2
On Fri, Dec 07, 2018 at 06:50:49PM -0500, [hidden email] wrote:
> Hey, that's not fair -- you answered my question before I even asked it! ;-)  
> But I included my findings below
>
It is totally fair, as it was part of your original problem statement:
https://lists.debian.org/debian-user/2018/12/msg00144.html

:-)

Regards,

-Roberto

--
Roberto C. Sánchez