Package Details: abseil-cpp 20200225.2-2

Git Clone URL: https://aur.archlinux.org/abseil-cpp.git (read-only, click to copy)
Package Base: abseil-cpp
Description: Abseil Common Libraries (C++)
Upstream URL: https://github.com/abseil/abseil-cpp
Licenses: Apache
Submitter: akstrfn
Maintainer: akstrfn
Last Packager: akstrfn
Votes: 0
Popularity: 0.000000
First Submitted: 2018-08-21 19:08
Last Updated: 2020-05-14 11:56

Dependencies (2)

Required by (1)

Sources (1)

Latest Comments

1 2 3 Next › Last »

keithspg commented on 2020-06-12 01:25

@oi_wtf That worked... for armv7. I used 1 thread and needed to make a swap file and it compiled. My armv6 is in a chroot on the Pi3b+, I have been able to build most everything, including the kernel. I cannot build this, though. It only gets 18% and quits with this:

[ 18%] Linking CXX executable ../../bin/absl_call_once_test
/usr/bin/ld: libabsl_spinlock_wait.a(spinlock_wait.cc.o): in function `AbslInternalSpinLockDelay':
spinlock_wait.cc:(.text+0x38): undefined reference to `__atomic_load_8'
/usr/bin/ld: spinlock_wait.cc:(.text+0x68): undefined reference to `__atomic_store_8'
/usr/bin/ld: libabsl_spinlock_wait.a(spinlock_wait.cc.o): in function `absl::lts_2020_02_25::base_internal::SpinLockSuggestedDelayNS(int)':
spinlock_wait.cc:(.text+0x1c4): undefined reference to `__atomic_load_8'
/usr/bin/ld: spinlock_wait.cc:(.text+0x1f8): undefined reference to `__atomic_store_8'
collect2: error: ld returned 1 exit status
make[2]: *** [absl/base/CMakeFiles/absl_call_once_test.dir/build.make:127: bin/absl_call_once_test] Error 1
make[1]: *** [CMakeFiles/Makefile2:1919: absl/base/CMakeFiles/absl_call_once_test.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

I have no problem building the git version of ashuffle (The reason I am trying to build this) on either platform, so I'll stick with that.

oi_wtf commented on 2020-06-10 20:30

@keithspg: Back to getting this package compiled on ARM: There may be a few things you could try to get it to build on your Pi:

Did you have MAKEFLAGS=-j4 or something similar defined anywhere, maybe makepkg.conf? If only one GCC process runs at any time, RAM may be sufficient.

Do you have swap enabled? It may help. Even if its just a temporary swapfile enabled using dd if=/dev/zero of=somefile bs=1M count=1024; mkswap somefile; swapon somefile (as root). I was able to build fine on my Pi2 with -j1 and swap.

(as an aside: I'd be really surprised if someone would request "PDP-11" arch... :D or any other than ARM-family or x86-family. There is also makepkg -A.)

akstrfn commented on 2020-06-10 16:52

I understand the problem and the current solution is not great but do you realise how long would arch line be if one would put all valid architectures? https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures

You need arm but someone else might come with some other request so "any" works everywhere as a workaround (if you dont copy binaries around...). I think I had one package where someone requested to add arm after which I realized that arch=() is not the correct way to handle aur packages that can be installed on multiple architectures.

keithspg commented on 2020-06-10 16:22

@akstrfn Then this is the only AUR I have come across that builds a package as -any.pkg.tar.xz that does not install on any* architecture. I understand what you are saying, but disagree with how you are interpreting the makepkg standard. I have some packages that I build for armv6 and armv7 which are 'any'. They are python scripts and the resultant package can be installed on any architecture (x86-64, armv6h, armv7h, etc). If the package has object components, pacman needs to know whether or not the package can be installed on the target architecture that pacman is running on. The way it knows (as far as I know) is the presence of the -armv6h.pkg.tar.xz on the name of the resultant package file. If it says 'any', it installs it regardless. If it is different than the architecture that it is running on, pacman will not install it as it knows it is the wrong architecture. If you change the line from:

arch = ('any')

to

arch = ('i686' 'x86_64' 'armv6h' 'armv7h' 'aarch64')

it will behave as you (and I and oi_wtf) expect. 'makepkg' will compile a binary on whatever system it is running on and the resultant package will have the info of that architecture in the generated filename. When installed, pacman can know whether to install it on the architecture that pacman is running on.

akstrfn commented on 2020-06-10 15:11

@oi_wtf Sorry for not being more clear that I know that there are object files after compilation and that the disagreement is about the meaning of "any" in terms aur. You are right that it can lead to confusion as it did in the case of keithspg since I made a wrong assumption that people who use abseil-cpp are actually devs who work with cpp and know that you cannot copy binaries like that. In principle "any" needs to be revised because a lot of compiles packages work on a lot of places after compilation to target architecture e.g. go or rust packages. CPython should gain automatic compilation of C extension as well in the next python version I believe. :)

@keithspg To reiterate my point, Arch regular package repos or Arch ARM repos distribute binaries whereas aur doesnt (mostly).

oi_wtf commented on 2020-06-10 14:57

Well, it leads to false assumptions and confusion by those who know what any usually means in the context Arch Linux, because you're using a different definition. As shown by the example of keithspg's assumption that abseil-cpp built on x86-64 could be used on armv7h.

It contains object files, because .a files are are collections of object files, that is what I wanted to show. objdump -a lists the object files an .a file contains.

But it seems we can only agree to disagree about what any means, so I'll for my part leave it at that. I have said all I can say and will say no more.

keithspg commented on 2020-06-10 14:56

@akstrfn I believe @oi_wtf is right. Please read this: https://wiki.archlinux.org/index.php/PKGBUILD#arch This is how I have used it as I have made PKGBUILD files for other packages intended for armv6/7 and x64. This also appears to be the convention used by other AURs, Arch ARM packages and regular Arch packages.

akstrfn commented on 2020-06-10 14:41

I saw that namcap output and I don't care about it because it is meaningless.

akstrfn commented on 2020-06-10 14:38

This is a pkg file and it does not have any object files so I am not sure what you are showing me with your builds. Its not "even if you compile it yourself", this is aur so you "must" compile it yourself. So "any" on aur can only signify that you can compile it anywhere. The arch guidelines are not suitable here. I for sure am not gonna put long list of architectures that gcc supports.

oi_wtf commented on 2020-06-10 14:17

And if I cannot convince you, maybe namcap can:

% namcap /var/cache/pacman/pkg/abseil-cpp-20200225.2-2-any.pkg.tar.zst
abseil-cpp E: ELF file ('usr/lib/libabsl_bad_any_cast_impl.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_bad_optional_access.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_bad_variant_access.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_base.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_city.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_civil_time.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_cord.a') found in an 'any' package.
abseil-cpp E: ELF file ('usr/lib/libabsl_debugging_internal.a') found in an 'any' package.
[...]