Package Details: global 6.6.2-3

Git Clone URL: (read-only)
Package Base: global
Description: A source code tag system
Upstream URL:
Licenses: GPL
Submitter: None
Maintainer: frealgagu
Last Packager: frealgagu
Votes: 121
Popularity: 1.286517
First Submitted: 2007-03-05 00:02
Last Updated: 2018-03-15 21:18

Latest Comments

watersalesman commented on 2018-02-10 16:29

Strange...updpkgsums didn't update the hash the first time.

The proper hash should be in the PKGBUILD now.

h-michael commented on 2018-02-10 16:18

After replacing sha256 with "43c64711301c2caf40dc56d7b91dd03d2b882a31fa31812bf20de0c8fb2e717f", I could buil pkg.

totsilence commented on 2018-02-10 10:20

I'm getting "==> ERROR: One or more files did not pass the validity check!" when building global 6.6.2-1. My sha256sum of global-6.6.2.tar.gz is "43c64711301c2caf40dc56d7b91dd03d2b882a31fa31812bf20de0c8fb2e717f" after download...

elimirks commented on 2017-12-29 21:56

Autoreconf currently breaks the build. I fixed it by commenting out line 32 (autoreconf -fi) and it seems to work fine.

Light2Yellow commented on 2017-10-26 14:47

Still fails for me due to:
/usr/bin/ld: cannot find -ltinfo
Is ncurses required to build this? If so, and if there is some issue, is it possible to depend on different versions? So that for ncurses<smth.smth libtinfo is required and for ncurses>=smth.smth it is not?

UPD. Never mind, Manjaro has just issued an update, so I no longer experience any issues.

watersalesman commented on 2017-10-24 23:39

It should be good now. With the new version of ncurses, the input.o object file needs to be compiled with the -ltinfo flag as well. I manually added the cflag in the PKGBUILD.

EDIT: It was an issue with the PKGBUILD. The TU maintaining ncurses has a new release in testing that fixes the issue. I will edit this PKGBUILD once that new ncurses release hits the core repo.

The bug report for those who are interested:

watersalesman commented on 2017-10-24 21:20

@pspencil After looking into it, it appears to be problem (or at least a compatibility issue) with the most recent version of ncurses. A temporary workaround is to downgrade to the previous version. If you have it cached locally, you can run something like:

sudo pacman -U /var/cache/pacman/pkg/ncurses-6.0+20170902-1-x86_64.pkg.tar.xz

or install it directly from the Arch Linux archive using:

sudo pacman -U

I will need to see if this is an Arch Linux packaging issue, or an upstream bug for global or ncurses.

pspencil commented on 2017-10-24 18:17

I got linker error while buiding. The same happens for tar.gz downloaded from gnu website. Am I missing some dependency?

Making all in gtags-cscope
make[2]: Entering directory '/home/pspencil/tmp/global-6.5.7/gtags-cscope'
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o gtags-cscope gtags-cscope.o alloc.o basename.o
build.o command.o display.o edit.o exec.o find.o help.o history.o input.o logdir.o mouse.o mygetenv.o mypop
en.o ../libparser/libgloparser.a ../libutil/libgloutil.a ../libdb/libglodb.a ../libglibc/libgloglibc.a -llt
dl -lncurses
libtool: link: gcc -g -O2 -o gtags-cscope gtags-cscope.o alloc.o basename.o build.o command.o display.o edi
t.o exec.o find.o help.o history.o input.o logdir.o mouse.o mygetenv.o mypopen.o ../libparser/libgloparser
.a ../libutil/libgloutil.a ../libdb/libglodb.a ../libglibc/libgloglibc.a -lltdl -lncurses
/usr/bin/ld: input.o: undefined reference to symbol 'erasechar'
/usr/lib/ error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

torpesco commented on 2017-05-15 19:52

@watersalesman - Thanks!

watersalesman commented on 2017-05-15 18:39

@torpesco Changed it.

6.5.7 should be up on the FTP site relatively soon. I'm sticking to this source because of the aforementioned connectivity issues.

For those who are eager for the update, here is the PKGBUILD using tamacom as the source:

torpesco commented on 2017-05-15 17:04

If we must stick with due to connectivity issues with, at least using HTTPS would be more secure:

6.5.7 has been released, but it hasn't made its way to the GNU site yet. Makes it more annoying to update the AUR package after releases. :-\

rpodgorny commented on 2017-04-16 18:02

@watersalesman thanks!

@albert748 ftp is everything but secure. :-( let's get rid of that ancient protocol! ...still, i get your troubles - but the correct thing would be to "fix" china's great firewall. ;-)

watersalesman commented on 2017-04-15 04:11

I just adopted the package because it looked like some things needed changing. I'm not too familiar with the package, so if anyone would like to take over, let me know. Otherwise I have no problem keeping it updated.

@jpkotta I added sqlite support

@albert748 I changed the source to the GNU ftp site

jpkotta commented on 2017-04-12 17:41

Can sqlite support be added? It's required for gogtags, and I'd rather not make a new global-sqlite package. sqlite is already a dep of pacman.

diff --git a/PKGBUILD b/PKGBUILD
index 9e0fd76..7947bbc 100644
@@ -4,12 +4,12 @@

pkgdesc="A source code tag system"
arch=('i686' 'x86_64')
-depends=('libltdl' 'bash' 'perl')
+depends=('libltdl' 'bash' 'perl' 'sqlite')
optdepends=('idutils' 'ctags' 'python-pygments' 'emacs' 'vim')
options=(!emptydirs !libtool)
@@ -30,7 +30,7 @@ prepare() {
build() {
cd "${srcdir}/${pkgname}-${pkgver}"
autoreconf -fi
- ./configure --prefix=/usr --with-exuberant-ctags=/usr/bin/ctags
+ ./configure --prefix=/usr --with-exuberant-ctags=/usr/bin/ctags --with-sqlite3

zyzero commented on 2016-12-14 21:14


had the same problem, worked for me after downloading global-6.5.5.tar.gz from gnu ftp ( No idea if that was a good idea though -.-

theherk commented on 2016-12-13 02:52

Can't build.


==> ERROR: One or more files did not pass the validity check!

updpkgsums (works)
tar -xvf global-6.5.5.tar.gz

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

albert748 commented on 2016-09-24 12:53

@ptrv could you please change source download url to gnu home:

It's more secure and is block from china, and may confuse user a lot.

ptrv commented on 2016-05-22 12:25

@dvzrv Thanks for pointing out to uncomment the vim plugin installation. Is fixed now. I added also emacs and vim as optional dependencies.

dvzrv commented on 2016-05-22 12:01

@ptrv: Thx for following up on my suggestion regarding moving in $pkgdir!
What about the vim plugins though? ;-)
Is there any reason to leave their move commented?
I've tried and tested this with current vim and it gets picked up flawlessly.

btw: You can add emacs and vim to optdepends for integrational purposes.

dvzrv commented on 2016-05-17 20:24

@ptrv: Can you also add the vim plugins at their system-wide destinations, please?
I suggest moving within $pkgdir though, as it is mostly the cleaner approach (will show up properly in pacman's listing of the package's files):

install -d "${pkgdir}/usr/share/emacs/site-lisp"
mv "${pkgdir}/usr/share/gtags/gtags.el" "${pkgdir}/usr/share/emacs/site-lisp/gtags.el"
install -d "${pkgdir}/usr/share/vim/vimfiles/plugin"
mv "${pkgdir}/usr/share/gtags/gtags.vim" "${pkgdir}/usr/share/vim/vimfiles/plugin/gtags.vim"
mv "${pkgdir}/usr/share/gtags/gtags-cscope.vim" "${pkgdir}/usr/share/vim/vimfiles/plugin/gtags-cscope.vim"

This way vim will pick them up automagically.

ptrv commented on 2016-05-07 11:41

@lilydjgw Install file is removed.

lilydjwg commented on 2016-05-07 11:23

The install file is no longer needed as Pacman supports hooks now.

ptrv commented on 2016-04-10 17:54

@blueyed Added global patch to use lid-idutils executable

blueyed commented on 2016-04-06 11:10

`lid` from idutils in Arch is installed as `idutils-lid` (

There does not appear to be a `--with-idutils(-lid)` option (should be proposed upstream probably?!) to specify the non-default location.
For now, global could be patched in Arch to use the `idutils-lid` program/location?

chopps commented on 2016-02-25 09:45

+1 on changing python2 to python (remove dependency and udpate to python-pygments). It just works and eliminates the python2 requirement.

eagletmt commented on 2016-01-11 02:20

Please add python2 to the makedepends array.
python2 is required to make the package.

NoSuck commented on 2015-04-13 05:12

Pity this isn't an official package anymore, as gtags seems to be superior to ctags in every respect.

Szunti commented on 2015-04-06 01:51

Why not delete the PYTHON=python2? It works with python3.
This also need a change of python2-pygments to python-pygments in dependencies.

tsdh commented on 2015-03-25 05:07

What's the relation between this package and the global package?

It looks to me like it's the very same, no? And the official name of gtags is GNU Global, so IMO the other package (which also has a much longer history) is the canonical one to be used.

torpesco commented on 2015-03-24 17:24


j.moyerman commented on 2015-02-05 18:16

With new version of automake in Arch repo's. It's necessary to rerun autoreconf in the build step.

build() {
cd "${srcdir}/${pkgname}-${pkgver}"
autoreconf -fi
PYTHON=/usr/bin/python2 ./configure --prefix=/usr --with-exuberant-ctags=/usr/bin/ctags


hav3lock commented on 2015-01-17 01:13

@naquad, kk. As for ``, lol, the diff did its job: I was curious as to whether it was necessary since it was unusual and confusing, especially given that the INSTALL file never mentioned it, although I didn't grep, I just skimmed through it.

Like I said, though, I apologize if I've been kind of a dick: nobody likes being told what to do or how they should be doing them.

naquad commented on 2015-01-16 14:47


I'll add python as optional dependency in the next version. stays, your diff shows that its not a bad idea.

I won't use sed command because patch shows exactly which lines are changed and in which file plus it'll stop building process if it won't be able to apply changes. Sed will silently quit if it won't find apply the change.

hav3lock commented on 2015-01-16 13:26

Or maybe `python` should be an optional dependency? I'm not sure. But it probably should be some kind of depend.

hav3lock commented on 2015-01-16 13:25


Hey, no problem. :)

About python: run `pacman -Ql gtags | grep py` and you'll see that you might need to add `python` as a depend.

As far as the `` stuff: that's your call, but it feels weird, and the package seems to build and install just fine when using the good ole:

./configure --prefix=/usr
make DESTDIR="$pkgdir"

Also, about your patch: I went ahead and wrote quick sed script that'll do the exact same thing _without_ you having to do something as unorthodox as exporting a variable:

sed -i '/mkdir -p ${gtagsdir}/s/\${/$(DESTDIR)${/' $srcdir/global-$pkgver/gozilla/

Also, just because weird stuff like `` just doesn't sit right with me, I went ahead and built two versions of the package: one with the original PKGBUILD, and another with a modified one that didn't use ``.

I then decompressed the `.tar.xz` files using `xz` and then extracted one of them. Then using

tar --diff -f gtags-6.3.3-2-x86_64.pkg.tar usr | sed '/Uid/d; /Gid/d; /Mod time/d'

I checked to see what the differences were; here they are:

usr/lib/gtags/ Contents differ
usr/lib/gtags/ Contents differ
usr/bin/htags: Contents differ
usr/bin/global: Contents differ
usr/bin/gtags: Contents differ
usr/var/gtags: Mode differs
usr/share/gtags/BUILD_TOOLS: Size differs

So it's still up to you; given that a couple *.so files have different contents... I'd be included to just stick with ``, lulz.

Anyway, sorry, I feel like I'm being kind of a dick here, being super nit-picky, I mean.

naquad commented on 2015-01-16 12:01


Thank you for your comments, I've fixed most of the issues with the gtags build (except python, looks like its more a namcap issue).

Regarding ``: it is used in official installation documentation ( and I would like it to keep it this way. There are no exotic dependencies for it so it doesn't require any extra stuff.

hav3lock commented on 2015-01-16 04:57

The `' utility script, which may be unnecessary (I don't know, but it feels off), uses gperf, bison, and flex. Please add these to the makedepends.

Also please use `namcap' on both the PKGBUILD and the resulting PKG.tar.xz file.

torpesco commented on 2014-12-17 01:55

6.3.3 is working fine for me so far. I know I'd like someone to take on the maintainer role for global...

triforce commented on 2014-12-16 08:55

I can take this on if you are happy using those?

torpesco commented on 2014-12-05 22:19

This seems to work for me.


torpesco commented on 2014-12-05 21:52

I took a stab at updating the PKGBUILD for myself and it seems there may be a problem in 6.3.3's "make install":

make install-data-hook
make[3]: Entering directory '/tmp/yaourt-tmp-james/aur-global/src/global-6.3.3/gozilla'
mkdir -p /usr/var/gtags
mkdir: cannot create directory ‘/usr/var’: Permission denied
Makefile:737: recipe for target 'install-data-hook' failed
make[3]: *** [install-data-hook] Error 1

Looks like the culprit is in gozilla/ The following was added between 6.3.2 and 6.3.3:

# for osx-default
gtagsdir = ${localstatedir}/gtags
mkdir -p ${gtagsdir}
chmod 777 ${gtagsdir}

I'm not well-versed in automake or makepkg/PKGBUILD, and I don't have time to investigate further at this point. I can't say I like the look of that chmod. Also, I don't even have a /usr/var directory.

migrev commented on 2014-12-05 09:58

I'll disown this package, as I don't actually use it and surely someone will be able of giving it more love than I can.

bladtman commented on 2014-11-17 12:57

I can't seem to get it working with pygments. My latest attempt was simply to install pygments (as well as ctags) before building global.
I've tried using gtags and global in both a ruby and haskell project without luck.
Any pointers?

eagletmt commented on 2014-11-02 12:48

@migrev: 'python2' must be included in makedepends.

migrev commented on 2014-09-09 15:21

@ackalker: Bump with your proposed changes, also got rid of libtool per @kolewu comment. Please check that everything works for you and thanks for the feedback.

ackalker commented on 2014-09-09 14:37

python2 -> python2-pygments
This should pull in python2 as well.

ackalker commented on 2014-09-09 14:31

Ah, and please also fix /usr/share/gtags/script/ to use:

The Pygments plug-in parser isn't compatible with Python 3.x.

ackalker commented on 2014-09-09 14:30

Ah, and please also fix /usr/share/gtags/script/ to use:
#!/usr/bin/env python2

The Pygments plug-in parser isn't compatible with Python 3.x.

ackalker commented on 2014-09-09 14:22

Please add optional dependency on python2: to use the Pygments plug-in parser.
This was newly added in GLOBAL 6.3.2, see [1],[2].
Thanks in advance.

[2]: /usr/share/gtags/PLUGIN_HOWTO.pygments

kolewu commented on 2014-04-06 12:32

The plugins configured in the default gtags.conf don't work cause the are called via .la-files. So you have to either change option '!libtool' to 'libtool' or directly use the .so-libs by including this before configure:

sed -i 's/\.la/.so/g'

ackalker commented on 2013-02-06 05:28

Updated to version 6.2.7, also fixed install info file:

jedbrown commented on 2012-06-03 15:23

This version dumps core for me. Updating to 6.2.4 worked.

Schnouki commented on 2012-02-24 16:03

Bonus point: add ctags to optdepends and "--with-exuberant-ctags=/usr/bin/ctags" to ./configure so you can use the exuberant-ctags plugin.

Schnouki commented on 2012-02-24 14:49

Updated for 6.2.1:
- global.install:

- version bump
- add a missing dependency reported by namcap
- add "!emptydirs" to options
- don't include global.install in source array
- don't create symlink to gtags.el in install but in PKGBUILD (so that it belongs to the package and can be removed)
- don't use absolute paths in the install file

corrupt commented on 2012-01-06 17:46

Tried to install - got an error during post-install install-info.
To fix remove .gz from PKGBUILD post_install, pre_remove.
So instead of
it should be

ryuslash commented on 2011-09-17 06:48

I didn't, but it seems to have had to do with the fact that I was compiling it with clang. Now that I've tried it with gcc it seems to work fine.

Thanks for the help and sorry for wasting your time :)

lucasdemarchi commented on 2011-09-17 00:09

Maybe you have an old configuration under /etc? We don't ship any configuration anymore.

I'm using it with kernel, bluez, connman source without any problems.

ryuslash commented on 2011-09-15 20:58

Oh and also, it's using up 99% of my CPU

ryuslash commented on 2011-09-15 20:34

Trying to run gtags on, for example, dwm seems to run indefinately, it gets stuck on the first file it finds and doesn't say anything more. Using `gtags -v' shows that it starts scanning a file and then just keeps waiting. Anything I can do/try?

Anonymous comment on 2011-03-29 21:30

source package:
i686 compiled package:

Anonymous comment on 2011-03-12 12:26

5.9.4 is released.

goodmen commented on 2010-09-03 05:46

Hi, 5.9.2 released!

goodmen commented on 2010-09-03 05:42

good! I love it!

lucasdemarchi commented on 2010-07-20 11:58

I updated the package. However, idutils and perl>=4 are optional dependencies

evaryont commented on 2010-07-11 03:18

global 5.9 has been released.

Also, perhaps adding `idutils' and `perl>=4' to the dependencies would be appropriate? They are depedencies. See src/global-5.9/INSTALL

For reference, idutils (in AUR) enables the -I flag in global(1) and perl enables the support of --form and --dynamic in htags(1)