@gnaggnoyil, the PKGBUILD
should use -DCMAKE_INSTALL_PREFIX="/usr"
and DESTDIR="${pkgdir}" cmake --install ...
.
@tleican, VCS sources should still use checksums for integrity verification. Please use updpkgsums
or makepkg -g >> PKGBUILD
.
Git Clone URL: | https://aur.archlinux.org/telegram-tdlib.git (read-only, click to copy) |
---|---|
Package Base: | telegram-tdlib |
Description: | Cross-platform library for building Telegram clients |
Upstream URL: | https://core.telegram.org/tdlib |
Keywords: | tdlib telegram |
Licenses: | boost |
Conflicts: | telegram-tdlib |
Provides: | telegram-tdlib |
Submitter: | tleican |
Maintainer: | tleican |
Last Packager: | tleican |
Votes: | 15 |
Popularity: | 0.046776 |
First Submitted: | 2018-05-16 09:26 (UTC) |
Last Updated: | 2025-09-25 02:41 (UTC) |
@gnaggnoyil, the PKGBUILD
should use -DCMAKE_INSTALL_PREFIX="/usr"
and DESTDIR="${pkgdir}" cmake --install ...
.
@tleican, VCS sources should still use checksums for integrity verification. Please use updpkgsums
or makepkg -g >> PKGBUILD
.
The built package gives the following content in /usr/lib/pkgconfig/tdapi.pc
prefix=/build/telegram-tdlib/pkg/telegram-tdlib/usr
Name: tdapi
Description: Telegram Library - API
Version: 1.8.51
CFlags: -I"${prefix}/include"
Libs: -L"${prefix}/lib" -ltdapi
Requires.private: tdutils
I don't think that's a working pkg-config file compared to the location the package put its files into. Does anyone know how to resolve this?
Upstream rarely provides releases or tags for their lib. They rely on a single git commit message where they bump the version most of the time. This is not great.
Most users want a package that is not 2 years old, which means we need a compromise. We use the Git commit hash that announces a release upstream. That means we can no longer provide a hash (sha-256, sha-512) to verify that what we got from git clone
matches the libtd that was released on GitHub.
Won't compile (same issue as in libtd):
==> Starting build()...
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
The current PKGBUILD does not generate correct pkgconfig configurations.
--- a/a
+++ b/b
@@ -19,12 +19,12 @@ sha256sums=('30d560205fe82fb811cd57a8fcbc7ac853a5b6195e9cb9e6ff142f5e2d8be217')
build() {
mkdir -p "td-$pkgver/build"
cd "td-$pkgver/build"
- cmake -DCMAKE_INSTALL_PREFIX="${pkgdir}/usr" -DCMAKE_BUILD_TYPE=Release ..
+ cmake -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_BUILD_TYPE=Release ..
cmake --build .
}
package() {
cd "td-$pkgver/build"
mkdir -p ${pkgdir}/usr
- cmake --build . --target install
+ make DESTDIR=${pkgdir} install
}
A note before you flag this out of date. :)
Telegram's main developer will tag stable releases on Github, and that is what is packaged here. See this comment from the main developer about requesting a 1.7 tag while 1.6 was the lastest tagged version:
The last release is still 1.6.0. All later version are development versions with continuously changing API. They all can be called 1.7.0-beta-X instead. Before TDLib 1.5.0 they wasn't even published on Github until next minor release. The 1.7.0 version will have a tag as soon it is ready.
Unless you can make Telegram change their mind about tagging, this is what you get here: a stable version.
If you need the latest unstable version, based on commit messages, check out libtd, it's fine! (Except it also brings PHP. 😅.)
Another way is to enable lto fat objects read here: https://archlinux.org/todo/lto-fat-objects/
@ephoz: If the user has the option lto in makepkg.conf enabled it breaks the static archives since stripping of static archives isn't supported with lto enabled.
@Thaodan What do you mean? I was under the impression that LTO was not enabled by default, assuming you meant -DTD_ENABLE_LTO=ON
here.
Pinned Comments
tleican commented on 2025-04-15 21:28 (UTC)
Upstream rarely provides releases or tags for their lib. They rely on a single git commit message where they bump the version most of the time. This is not great.
Most users want a package that is not 2 years old, which means we need a compromise. We use the Git commit hash that announces a release upstream. That means we can no longer provide a hash (sha-256, sha-512) to verify that what we got from
git clone
matches the libtd that was released on GitHub.