Version outdated

Bug #1606142 reported by AlexanderBurger on 2016-07-25
This bug affects 5 people
Affects Status Importance Assigned to Milestone
picolisp (Debian)
Fix Released
picolisp (Ubuntu)

Bug Description

PicoLisp in yakkety is still on 15.11-1, while
the current version in Debian Stretch is already
on 16.6.

Why is it not more up to date?

Hans Joachim Desserud (hjd) wrote :

Thanks for taking your time to report this issue and help making Ubuntu better.

Version 16.6-2 has been synced to yakkety-proposed [1], which is the staging area for new packages. Unfortunately it fails to build on amd64 which keeps it from migrating over to the regular yakkety archive. It fails with the following error message, though I don't know why:
make[2]: Entering directory '/«PKGBUILDDIR»/src64'
./mkAsm x86-64 ".linux" .s Linux base "" ../lib/map version.l glob.l main.l gc.l apply.l flow.l sym.l subr.l big.l io.l db.l net.l err.l sys/x86-64.linux.code.l
./mkAsm x86-64 ".linux" .s Linux ext T "" ext.l
./mkAsm x86-64 ".linux" .s Linux ht T "" ht.l
as -o x86-64.linux.base.o x86-64.linux.base.s
cc -o ../bin/picolisp x86-64.linux.base.o -Wl,--no-as-needed -rdynamic -lc -lm -ldl -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now
/usr/bin/ld: x86-64.linux.base.o: relocation R_X86_64_32S against `Nil' can not be used when making a shared object; recompile with -fPIC
x86-64.linux.base.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
(see for more details)


tags: added: ftbfs upgrade-software-version yakkety

Thanks for the answer.

I understand the problem. Unfortunately, the PicoLisp amd64 base system cannot
be compiled as position independent code (i.e. the -fpic option of C compilers),
because it is written as a special VM in assembly language.

Is there no other way, keeping the core executable with positioned code? This
was no problem until now, and still works on other systems (e.g. Debian).

This was not a rhetorical question.

What I mean is: Please do it the same way as Debian does it.

As the Debian developer told me, it is just a matter of not enabling all hardening flags.


Hans Joachim Desserud (hjd) wrote :

It looks like the default build flags has changed (, and this issue also affects Debian now (see the upstream bug report). So it looks like this package might need to opt-out in some way.

Changed in picolisp (Debian):
status: Unknown → New
Changed in picolisp (Debian):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in picolisp (Ubuntu):
status: New → Confirmed
Mike Pechkin (mike-pechkin) wrote :

I, @tankfeeder in twitter, freenode, telegram help you update version of this.
5min issue, just do it.

On Tue, Dec 27, 2016 at 07:39:26PM -0000, Mike Pechkin wrote:
> I, @tankfeeder in twitter, freenode, telegram help you update version of this.

Ah, cool! Many thanks! :)

> 5min issue, just do it.

So how did it work? You just posted messages? Is there something I should do

- Alex

Andreas Rüegger (beneroth) wrote :


As a long-time Ubuntu user (work machines for programming and on servers) and heavy user of the programming language picolisp, I would greatly wish for a up-to-date picolisp package in Ubuntu.

The isse here seems to be the rather simple change of Ubuntu having switched to always pass the PIE flag when building.

picolisp is an interpreter virtual machine, the picolisp language itself allows no access to pointers, as the concept of pointers as native memory address is completely lacking in this lisp language.
The category of bugs and security vulnerabilities against which PIE protects are not possible with picolisp by concept (other types of vulnerabilities - introduced by negligent application programmers - are of course well possible).

SBCL (another lisp implementation) had the same PIE-issue with yakkety,
where it was solved by providing -no-pie flags to GCC to disable -fPIE.

The same was the case with picolisp on debian, which it was resolved by using the -no-pie flags.

Please apply the same solution to this picolisp package in Ubuntu.

Thanks for your support.
Any questions regarding picolisp and picolisp security measurements are warmly welcome.

Regards, beneroth

Andreas Rüegger (beneroth) wrote :

The only obstacle to a up-to-date picolisp package is adding the -no-pie flag when building.

As there are now even javascript attacks to circument PIE/ASLR protection measures,
the general importance PIE as security enhancement has surely dropped heavily.

So even less reason to deny -no-pie.


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.