undefined symbol: tgetent

Bug #1683761 reported by Andreas Schildbach on 2017-04-18
This bug affects 46 people
Affects Status Importance Assigned to Milestone
Fix Released
libnative-platform-java (Ubuntu)

Bug Description

This is a regression in zesty: When starting gradle, I always get

java: symbol lookup error: /usr/lib/jni/libnative-platform-curses.so: undefined symbol: tgetent

Apparently, this is a recurring bug. It was also present in 13.10: https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1238322

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: gradle 3.2.1-1
ProcVersionSignature: Ubuntu 4.10.0-19.21-generic 4.10.8
Uname: Linux 4.10.0-19-generic x86_64
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Tue Apr 18 13:39:55 2017
InstallationDate: Installed on 2013-01-11 (1557 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
PackageArchitecture: all
SourcePackage: gradle
UpgradeStatus: Upgraded to zesty on 2017-04-08 (9 days ago)

Andreas Schildbach (schildbach) wrote :
affects: gradle (Ubuntu) → libnative-platform-java (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in libnative-platform-java (Ubuntu):
status: New → Confirmed
Niklas Sombert (ytvwld) wrote :
Download full text (5.7 KiB)

I've ran into the same issue.

After reading https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1238322/comments/8, I installed the package from Debian: https://packages.debian.org/sid/libnative-platform-jni.

This works only partially. It fails with a different error message:

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.ExceptionInInitializerError (no error message)

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
        at org.gradle.initialization.DefaultClassLoaderRegistry.restrictTo(DefaultClassLoaderRegistry.java:40)
        at org.gradle.initialization.DefaultClassLoaderRegistry.restrictToGradleApi(DefaultClassLoaderRegistry.java:36)
        at org.gradle.initialization.DefaultClassLoaderRegistry.<init>(DefaultClassLoaderRegistry.java:30)
        at org.gradle.internal.service.scopes.GlobalScopeServices.createClassLoaderRegistry(GlobalScopeServices.java:215)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:547)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.internal.service.DefaultServiceRegistry.invoke(DefaultServiceRegistry.java:462)
        at org.gradle.internal.service.DefaultServiceRegistry.access$1200(DefaultServiceRegistry.java:84)
        at org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:796)
        at org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:752)
        at org.gradle.internal.service.DefaultServiceRegistry$ManagedObjectProvider.getInstance(DefaultServiceRegistry.java:589)
        at org.gradle.internal.service.DefaultServiceRegistry$SingletonService.get(DefaultServiceRegistry.java:634)
        at org.gradle.internal.service.DefaultServiceRegistry.applyConfigureMethod(DefaultServiceRegistry.java:253)
        at org.gradle.internal.service.DefaultServiceRegistry.findProviderMethods(DefaultServiceRegistry.java:214)
        at org.gradle.internal.service.DefaultServiceRegistry.addProvider(DefaultServiceRegistry.java:352)
        at org.gradle.internal.service.ServiceRegistryBuilder.build(ServiceRegistryBuilder.java:52)
        at org.gradle.launcher.cli.BuildActionsFactory.createGlobalClientServices(BuildActionsFactory.java:153)
        at org.gradle.launcher.cli.BuildActionsFactory.runBuildWithDaemon(BuildActionsFactory.java:108)
        at org.gradle.launcher.cli.BuildActionsFactory.createAction(BuildActionsFactory.java:83)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.createAction(CommandLineActionFactory.java:249)
        at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239)
        at org.gradle.launcher.cli.CommandLineActionFacto...


Hilikus (hilikus) wrote :

I can confirm. Downloading https://packages.debian.org/sid/libnative-platform-jni and installing it with `dpkg --install libnative-platform-jni_0.11-5_amd64.deb` fixed the issue
I'm using lubuntu 17.04

Ronak Buch (synacksynack) wrote :

Installing https://packages.debian.org/sid/libnative-platform-jni (0.11-5_amd64) fixed this problem for me, too.

Woden Cafe (wodencafe) wrote :

I encountered this problem too, and like the others, installing https://packages.debian.org/sid/libnative-platform-jni (0.11-5_amd64) fixes it for myself.

I also want to mention this only happened with OpenJDK, when I switched java to the Oracle JDK, the problem also went away.

LI Zhuohuan (zixia) wrote :

I encountered this problem too, and after installing the libnative-platform-jni from debian, it went away.

My system is Ubuntu Gnome Desktop 17.04.

Mateusz Mikuła (mati865) wrote :
Changed in gradle:
status: Unknown → Fix Released
Andreas Schildbach (schildbach) wrote :

Thanks Mateusz, I added an "update request" issue to the Gradle package: https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1695919

Niklas Sombert (ytvwld) wrote :

It is still weird that this problem doesn't appear with the Debian package. They are both the same version.

Mateusz Mikuła (mati865) wrote :

I compared Ubuntu sources and Debian sources, they are exactly the same.
The only difference I've found is related to dynamic relocations in /usr/lib/jni/libnative-platform-curses.so, adding screenshot.

I followed Hilikus (hilikus) instructions, and works for me.
Thanks a lot

Martin (martin3000) wrote :

In https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1238322 Eric writes it is a bug in the makefile. So the sources are the same.

Jonathan (jsuiker) wrote :

+1 for the fix of downloading the debian package


sudo dpkg --install libnative-platform-jni_0.11-5_amd64.deb

I'm using Ubuntu Desktop

David O'Connor (docky) wrote :

Downloading https://packages.debian.org/sid/libnative-platform-jni and installing it with `dpkg --install libnative-platform-jni_0.11-5_amd64.deb` fixed the issue for me too on Xubuntu 17.04

josergc (josergc) wrote :

In case of this helps: I installed the libnative-platform-jni_0.11-5_amd64.deb package 1+ month ago because I was getting the same problem in kubuntu 17.04. I remember there have been software upgrades since then. Today, I have tried to compile and the error was back. So that, to fix the problem, I had to reinstall the libnative-platform-jni_0.11-5_amd64.deb package.

same issue on Ubuntu 17.10 ... solution works as noted above ... download deb and install


sudo dpkg --install libnative-platform-jni_0.11-5_amd64.deb

Sebastian Ciuca (sebi023) wrote :

Hello. I also downloaded and installed the package (https://packages.debian.org/sid/amd64/libnative-platform-jni/download), but when checking my gradle version (gradle -v), I got :

"FAILURE: Build failed with an exception.

* What went wrong:
Unexpected native library version loaded. Expected 21, was 25.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output."

Does anyone know of a solution for this?

Sebastian Ciuca (sebi023) wrote :

(Fixed it by sudo apt-get remove gradle then re-installing it with sdk)

Oded Arbel (oded-geek) wrote :

Running Artful, I have the same problem. Installing latest from SID (i.e. 0.14 instead of Ubuntu's 0.11) causes "Unexpected native library version loaded. Expected 21, was 25."

In addition to that, Artful's gradle is pretty old - 3.2 compared to current 4.4. I've replaced it with gradle from cwchien's PPA: https://launchpad.net/~cwchien/+archive/ubuntu/gradle/+packages and it works great.

Kyle Gottfried (spitfire1900) wrote :

As noted by above, reproducible in Artful

Peter Schüller (schueller-p) wrote :

I have the same issue in Artful.

Sadly, Gradle in the current beta of upcoming 18.04 LTS is broken in the same way, too.


gradle 3.2.1-5
libnative-platform-jni 0.14-2
libnative-platform-java 0.14-2

Changed in libnative-platform-java (Ubuntu):
importance: Undecided → High
Laurent Bigonville (bigon) wrote :


I uploaded the following patch to artful.

For bionic, that should be fixed via a sync from debian

Changed in libnative-platform-java (Ubuntu Artful):
status: New → In Progress

Laurent, thanks a lot for looking into this!

Is there a particular action needed for starting the Debian sync? I'm asking because apparently there was no Debian sync for the last 1 year. At least that's the time the package has been broken in the various Ubuntu releases that happened since then.

Laurent Bigonville (bigon) wrote :

The debian package was wrong but not broken due to difference in the linker default options.

The last time the package has been synced is Nov 2017, so I think that should happen automatically with 0.14-3 upload from debian

FWIW, Debian import freeze for bionic was already on March 1.

According to https://wiki.ubuntu.com/DebianImportFreeze

"After this date, packages will only be imported from Debian in this way by explicit request from a developer."

With todays update of libnative-platform-java/jni, this issue is fixed in 18.04. Thanks again!

Changed in libnative-platform-java (Ubuntu Bionic):
status: Confirmed → Fix Released
Changed in libnative-platform-java (Ubuntu Artful):
importance: Undecided → High
Laurent Bigonville (bigon) wrote :

The fix I pushed for Artful is still not accepted for SRU

Laurent Bigonville (bigon) wrote :

The patch is really minimal, just move the linker (-l) flag at the end of the line.

Currently the libnative-platform-jni package in artful depends only on libc6, with the patch, it depends (on bionic) on libc6 and libtinfo5 as expected.

I don't really see a possible regression with that fix

Anders Hall (a.hall) wrote :

Solution in #20 worked partially but lead to a new problem (Build failed in my case).

"WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/usr/lib/gradle/4.6/lib/groovy-all-2.4.12.jar) to method java.lang.Object.finalize()"

This might be related to Java SDK 9 not being supported.

Laurent Bigonville (bigon) wrote :

SRU got rejected because I didn't follow the SRU procedure strictly enough.

Package is still broken in artful, someone that care enough he can take that over from me

Changed in libnative-platform-java (Ubuntu Artful):
status: In Progress → Confirmed
Tessa (unit3) wrote :

Just ran into this. pretty surprised we're still having issues with a bug that was first identified in 2013. Does anyone have workaround suggestions in the mean time?

Niklas Sombert (ytvwld) wrote :

Yes, there's a workaround.
You can install the package (with the same version) from Debian: https://packages.debian.org/stretch/libnative-platform-jni

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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