linux

A minimally configured Windows laptop

November 22, 2020 Windows No comments , , , , , ,

I’ve now installed enough that my new Windows machine is minimally functional (LaTex, Linux, and Mathematica), with enough installed that I can compile any of my latex based books, or standalone content for blog posts.  My list of installed extras includes:

  • Brother HL-2170W (printer driver)
  • Windows Terminal
  • GPL Ghostscript (for MaTeX, latex labels in Mathematica figures.)
  • Wolfram Mathematica
  • Firefox
  • Chrome
  • Visual Studio
  • Python
  • Julia
  • Adobe Acrobat Reader
  • Discord
  • OBS Studio
  • MikTeX
  • SumatraPDF
  • GVim
  • Git
  • PowerShell (7)
  • Ubuntu
  • Dropbox

Some notes:

  • On Windows, for my LaTeX work, I used to use MikTex + cygwin.  The cygwin dependency was for my makefile dependencies (gnu-make+perl).  With this new machine, I tried WSL2.  I’m running my bash shells within the new Windows Terminal, which is far superior to the old cmd.
  • Putty is no longer required.  Windows Terminal does the job very nicely.  It does terminal emulation well enough that I can even ssh into a Linux machine and use screen within my Linux session, and my .screenrc just works.  Very nice.
  • SumatraPDF is for latex reverse tex lookup.  i.e. I can double click on pdf content, and up pops the editor with the latex file.  Last time I used Sumatra, I had to configure it to use GVim (notepad used to be the default I think.)  Now it seems to be the default (to my suprise.)
  • I will probably uninstall Git, as it seems superfluous given all the repos I want to access are cloned within my bash file system.
  • I used to use GVim extensively on Windows, but most of my editing has been in vim in the bash shell.  I expect I’ll now only use it for reverse tex (–synctex) lookup editing.

WSL2 has very impressive integration.  A really nice demo of that was access of synctex lookup.  Here’s a screenshot that shows it in action:

I invoked the windows pdf viewer within a bash shell in the Ubuntu VM, using the following:

 
pjoot@DESKTOP-6J7L1NS:~/project/blogit$ alias pdfview
alias pdfview='/mnt/c/Users/peete/AppData/Local/SumatraPDF/SumatraPDF.exe'
pjoot@DESKTOP-6J7L1NS:~/project/blogit$ pdfview fibonacci.pdf

The Ubuntu filesystem directory has the fibonacci.synctex.gz reverse lookup index that Summatra is able to read. Note that this file, after unzipping, has only Linux paths (/home/pjoot/…), but Summatra is able to use those without any trouble, and pops up the (Windows executable) editor on the files after I double click on the file. This sequence is pretty convoluted:

  • Linux bash ->
  • invoke Windows pdf viewer ->
  • that program reading Linux files ->
  • it invokes a windows editor (presumably using the Linux path), and that editor magically knows the path to the Linux file that it has to edit.

Check out the very upper corner of that GVim window, where it shows the \\wsl$\Ubuntu\home\pjoot\project\blogit\fibonacci.tex path

As well as full Linux access to the Windows filesystem, we have full Windows access to the Linux filesystem.

Not all applications know how to access files with UNC paths (for example, the old crappy cmd.exe cannot), but so far all the ones I have cared about have been able to do so.

An example of Linux/glibc symbol versioning.

September 20, 2019 C/C++ development and debugging. 4 comments , , , , , , ,

Here’s a little introduction to Linux/glibc symbol versioning.  The sources, linker version scripts, and makefile from this post can be found here in github.

The definitive reference for this topic is Ulrich Drepper’s dsohowto document.

Linux symbol versioning is a very logical way to construct a definitive API for your product.  If you are careful, you can have a single version of your shared library that is binary compatible with all previous versions of code that have linked it, and additionally hide all symbols that you don’t want your API consumer to be able to use (as if all non-exported symbols have a “static” like scope within the library itself).

That visibility hiding can be done in other ways (such as using static, or special compiler options), but utilizing a symbol version linker script to do so also has all the additional binary compatibility related benefits.

Suppose that we have a “v1.1” API with the following implementation:

#include <stdio.h>

void internal_function_is_not_visible()
{
   printf( "You can't call me directly.\n" );
}

void foo( int x )
{
   internal_function_is_not_visible();

   printf( "foo@@V1: %d\n", x );
}

and we build this into a shared library like so:

$ make libfoo.1.so
rm -f libfoo.1.so
cc foo.c -g -Wl,--version-script=symver.map -fpic -o libfoo.1.so -Wl,-soname,libfoo.so -shared
rm -f libfoo.so
ln -s libfoo.1.so libfoo.so

Everything here is standard for building a shared library except for the –version-script option that is passed into the linker with -Wl,. That version script file has the following contents:

$ cat symver.map
MYSTUFF_1.1 {
	  global:
foo;
	  local: *;
	};

This defines a “V1.1” API where all the symbols that are exported with a symbol version @@MYSTUFF_1.1. Note that internal_function_is_not_visible is not in that list. It’s covered in the local: catch-all portion of the symbol version file. Code that calls foo does not look out of the ordinary:

void foo(int);

int main()
{
   foo(1);

   return 0;
}

Compiling and linking that code is also business as usual:

$ make caller1
cc caller.c -g -Wl,-rpath,`pwd` -o caller1 -lfoo -L.

However, look at the foo symbol reference that we have for this program:

$ nm caller1 | grep foo
                 U foo@@MYSTUFF_1.1

If we run this, we get:

$ ./caller1
You can't call me directly.
foo@@V1: 1

If you add in a call to internal_function_is_not_visible() you’ll see that compilation fails:

void foo(int);
void internal_function_is_not_visible();

int main()
{
   foo(1);
   internal_function_is_not_visible();

   return 0;
}

$ make caller1
cc caller.c -g -Wl,-rpath,`pwd` -o caller1 -lfoo -L.
/run/user/1002/ccqEPYcu.o: In function `main':
/home/pjoot/symbolversioning/caller.c:7: undefined reference to `internal_function_is_not_visible'
collect2: error: ld returned 1 exit status
make: *** [caller1] Error 1

This is because internal_function_is_not_visible is not a visible symbol. Cool. We now have versioned symbols and symbol hiding. Suppose that we now want to introduce a new binary incompatible change too our foo API, but want all existing binaries to still work unchanged. We can do so by introducing a symbol alias, and implementations for both the new and the OLD API.

#include <stdio.h>

void internal_function_is_not_visible()
{
   printf( "You can't call me directly.\n" );
}

void foo2( int x, int y )
{
   if ( y < 2 )
   {
      internal_function_is_not_visible();
   }
   printf( "foo@@V2: %d %d\n", x, y );
}

void foo1( int x )
{
   internal_function_is_not_visible();
   printf( "foo@@V1: %d\n", x );
}

This is all standard C up to this point, but we now add in a little bit of platform specific assembler directives (using gcc specific compiler sneaks) :

#define V_1_2 "MYSTUFF_1.2"
#define V_1_1 "MYSTUFF_1.1"

#define SYMVER( s ) \
    __asm__(".symver " s )

SYMVER( "foo1,foo@" V_1_1 );
SYMVER( "foo2,foo@@" V_1_2 );

We’ve added a symbol versioning alias for foo@@MYSTUFF_1.2 and foo@MYSTUFF_1.1. The @@ one means that it applies to new code, whereas the @MYSTUFF_1.1 is a load only function, and no new code can use that symbol. In the symbol version script we now introduce a new version stanza:

$ cat symver.2.map
MYSTUFF_1.2 {
	  global:
foo;
};
MYSTUFF_1.1 {
	  global:
foo;
	  local: *;
};

$ make libfoo.2.so
rm -f libfoo.2.so
cc foo.2.c -g -Wl,--version-script=symver.2.map -fpic -o libfoo.2.so -Wl,-soname,libfoo.so -shared
rm -f libfoo.so
ln -s libfoo.2.so libfoo.so

If we call the new V1.2 API program, like so:

void foo(int, int);
int main()
{
   foo(1, 2);
   return 0;
}

our output is now:

$ ./caller2
foo@@V2: 1 2

Our “binary incompatible changes” are two fold. We don’t call internal_function_is_not_visible if our new parameter is >= 2, and we print a different message.

If you look at the symbols that are referenced by the new binary, you’ll see that it now explicitly has a v1.2 dependency:

$ nm caller2 | grep foo
                 U foo@@MYSTUFF_1.2
%d bloggers like this: