Package Details: gcc44 4.4.7-6

Git Clone URL: https://aur.archlinux.org/gcc44.git (read-only, click to copy)
Package Base: gcc44
Description: The GNU Compiler Collection (4.4.x)
Upstream URL: http://gcc.gnu.org/
Licenses: GPL, custom, LGPL
Conflicts: gcc44-multilib
Submitter: None
Maintainer: severach
Last Packager: severach
Votes: 68
Popularity: 0.000000
First Submitted: 2010-05-28 14:46 (UTC)
Last Updated: 2021-09-30 00:34 (UTC)

Latest Comments

mshockwave commented on 2017-05-22 09:53 (UTC)

I came across with some failures that "x86_64-pc-linux-gnu" in tmp build directory is not found. It turns out that some PC would got "x86_64-unknown-linux-gnu" instead Add the following options for ./configure: --build=${CHOST}

hv15 commented on 2016-03-02 16:09 (UTC)

Hi Gryffyn, I was having the same issue as mentatf and found that the patched given by GloW wasn't working for me. So I had a look and found another patch from https://github.com/gccxml/gccxml/issues/11, which has solved the issue for me. The patch can be found at http://pastebin.com/tujjVNCs. For convenience I have created a new PKGBUILD: http://pastebin.com/1K1jN6gZ

mentatf commented on 2015-11-25 17:11 (UTC) (edited on 2015-11-25 21:25 (UTC) by mentatf)

@marker5a the patch given below doesn't work for me, the same error message posted by @agwblack remains. The steps I've followed are: 1) download the snapshot 2) extract it in some directory 3) add fix_gcc5.patch in it 4) add 3 lines in the PKGBUILD: 'fix_gcc5.patch', '"the checksum"' and "patch -Np0 -i "$srcdir/fix_gcc5.patch" 5) makepkg -sri edit: in the meantime, I manage to install it by downgrading gcc to 4.9.

marker5a commented on 2015-10-21 21:03 (UTC)

@GloW, thanks for handling that. I was trying to figure out ways to get the patch posted... didn't even think about pastebin :) Pardon the n00b question, is there a more elegant way to get patches submitted for aur packages? Or is that still a wip with the transition to git for managing the packages? Anyways, thanks again for your help GloW!

GloW commented on 2015-10-21 15:36 (UTC)

here is a corrected version of fix_gcc5.patch : http://pastebin.com/kUwW19Zj

GloW commented on 2015-10-21 07:22 (UTC)

@marker5a can't really use your patch, since identation is brokeN

marker5a commented on 2015-10-14 19:41 (UTC)

@agwblack, dieghen89... I did some digging and found a solution. You need to apply the following patch which adds a new patch file to the package and PKGBUILD. The patch addresses the issue of compiling this package using the newer versions of gcc diff --git a/PKGBUILD b/PKGBUILD index 77967f1..ec8abc8 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -20,11 +20,14 @@ options=('!libtool' '!buildflags' 'staticlibs') source=("http://www.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-$pkgver/gcc-$pkgver.tar.bz2" 'gcc-hash-style-both.patch' 'gcc_pure64.patch' - 'siginfo_t_fix.patch') + 'siginfo_t_fix.patch' + 'fix_gcc5.patch') sha256sums=('5ff75116b8f763fa0fb5621af80fc6fb3ea0f1b1a57520874982f03f26cd607f' 'a600550d3d2b2fb8ee6a547c68c3a08a2af7579290b340c35ee5598c9bb305a5' '2d369cf93c6e15c3559c3560bce581e0ae5f1f34dc86bca013ac67ef1c1a9ff9' - '4df866dcfd528835393d2b6897651158faf6d84852158fbf2e4ffc113ec7d201') + '4df866dcfd528835393d2b6897651158faf6d84852158fbf2e4ffc113ec7d201' + 'e4f1f0f7616ad5c72db4b0b02bce33c79b101277b705ec90da957dee14091d5e') + prepare() { cd "gcc-$pkgver" @@ -34,6 +37,7 @@ prepare() { # Do not run fixincludes sed -i -e 's:\./fixinc\.sh:-c true:' gcc/Makefile.in + patch -Np0 -i "$srcdir/fix_gcc5.patch" patch -Np0 -i "$srcdir/gcc-hash-style-both.patch" patch -Np1 -i "$srcdir/siginfo_t_fix.patch" if [[ "$CARCH" == "x86_64" ]]; then diff --git a/fix_gcc5.patch b/fix_gcc5.patch new file mode 100644 index 0000000..4959a77 --- /dev/null +++ b/fix_gcc5.patch @@ -0,0 +1,99 @@ +diff --git a/gcc/toplev.c b/gcc/toplev.c +index 267df59..4836238 100644 +--- gcc/toplev.c ++++ gcc/toplev.c +@@ -532,11 +532,11 @@ read_integral_parameter (const char *p, const char *pname, const int defval) + return atoi (p); + } + +-/* When compiling with a recent enough GCC, we use the GNU C "extern inline" +- for floor_log2 and exact_log2; see toplev.h. That construct, however, +- conflicts with the ISO C++ One Definition Rule. */ ++#if GCC_VERSION < 3004 + +-#if GCC_VERSION < 3004 || !defined (__cplusplus) ++/* The functions floor_log2 and exact_log2 are defined as inline ++ functions in toplev.h if GCC_VERSION >= 3004. The definitions here ++ are used for older versions of gcc. */ + + /* Given X, an unsigned number, return the largest int Y such that 2**Y <= X. + If X is 0, return -1. */ +@@ -549,9 +549,6 @@ floor_log2 (unsigned HOST_WIDE_INT x) + if (x == 0) + return -1; + +-#ifdef CLZ_HWI +- t = HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x); +-#else + if (HOST_BITS_PER_WIDE_INT > 64) + if (x >= (unsigned HOST_WIDE_INT) 1 << (t + 64)) + t += 64; +@@ -568,7 +565,6 @@ floor_log2 (unsigned HOST_WIDE_INT x) + t += 2; + if (x >= ((unsigned HOST_WIDE_INT) 1) << (t + 1)) + t += 1; +-#endif + + return t; + } +@@ -581,14 +577,10 @@ exact_log2 (unsigned HOST_WIDE_INT x) + { + if (x != (x & -x)) + return -1; +-#ifdef CTZ_HWI +- return x ? CTZ_HWI (x) : -1; +-#else + return floor_log2 (x); +-#endif + } + +-#endif /* GCC_VERSION < 3004 || !defined (__cplusplus) */ ++#endif /* GCC_VERSION < 3004 */ + + /* Handler for fatal signals, such as SIGSEGV. These are transformed + into ICE messages, which is much more user friendly. In case the +diff --git a/gcc/toplev.h b/gcc/toplev.h +index e62aa727..cca6867 100644 +--- gcc/toplev.h ++++ gcc/toplev.h +@@ -169,14 +169,17 @@ extern void decode_d_option (const char *); + extern bool fast_math_flags_set_p (void); + extern bool fast_math_flags_struct_set_p (struct cl_optimization *); + ++/* Inline versions of the above for speed. */ ++#if GCC_VERSION < 3004 ++ + /* Return log2, or -1 if not exact. */ + extern int exact_log2 (unsigned HOST_WIDE_INT); + + /* Return floor of log2, with -1 for zero. */ + extern int floor_log2 (unsigned HOST_WIDE_INT); + +-/* Inline versions of the above for speed. */ +-#if GCC_VERSION >= 3004 ++#else /* GCC_VERSION >= 3004 */ ++ + # if HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_LONG + # define CLZ_HWI __builtin_clzl + # define CTZ_HWI __builtin_ctzl +@@ -188,17 +191,18 @@ extern int floor_log2 (unsigned HOST_WIDE_INT); + # define CTZ_HWI __builtin_ctz + # endif + +-extern inline int ++static inline int + floor_log2 (unsigned HOST_WIDE_INT x) + { + return x ? HOST_BITS_PER_WIDE_INT - 1 - (int) CLZ_HWI (x) : -1; + } + +-extern inline int ++static inline int + exact_log2 (unsigned HOST_WIDE_INT x) + { + return x == (x & -x) && x ? (int) CTZ_HWI (x) : -1; + } ++ + #endif /* GCC_VERSION >= 3004 */ + + /* Functions used to get and set GCC's notion of in what directory

gajjanag commented on 2015-08-15 12:57 (UTC)

Thanks a lot for maintaining this old version. @agwblack, dieghen89: Built and tested successfully with oldest ARM (arch rollback machine) version of GCC, namely 4.8.1 (modulo the linker errors, see the recent discussion https://aur.archlinux.org/packages/gcc43/).

agwblack commented on 2015-07-20 14:37 (UTC)

I have the following error: ../../gcc/toplev.c: At top level: ../../gcc/toplev.c:536:1: error: redefinition of ‘floor_log2’ floor_log2 (unsigned HOST_WIDE_INT x) ^ In file included from ../../gcc/toplev.c:58:0: ../../gcc/toplev.h:190:1: note: previous definition of ‘floor_log2’ was here floor_log2 (unsigned HOST_WIDE_INT x) ^ ../../gcc/toplev.c:571:1: error: redefinition of ‘exact_log2’ exact_log2 (unsigned HOST_WIDE_INT x) ^ In file included from ../../gcc/toplev.c:58:0: ../../gcc/toplev.h:196:1: note: previous definition of ‘exact_log2’ was here exact_log2 (unsigned HOST_WIDE_INT x) ^ Makefile:2470: recipe for target 'toplev.o' failed make[3]: *** [toplev.o] Error 1 make[3]: Leaving directory '/tmp/makepkg/gcc44/src/gcc-4.4.7/build/gcc' Makefile:5142: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/tmp/makepkg/gcc44/src/gcc-4.4.7/build' Makefile:17112: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/tmp/makepkg/gcc44/src/gcc-4.4.7/build' Makefile:739: recipe for target 'all' failed make: *** [all] Error 2

dieghen89 commented on 2015-07-10 20:13 (UTC)

I have the following error: ../../gcc/tree-call-cdce.c: At top level: ../../gcc/tree-call-cdce.c:928:3: warning: enum constant defined in struct or union is not visible in C++ [-Wc++-compat] GIMPLE_PASS, ^ In file included from ../../gcc/tree-dump.h:26:0, from ../../gcc/tree-call-cdce.c:39: ../../gcc/tree-pass.h:102:5: note: enum constant defined here GIMPLE_PASS, ^ rm gcc.pod make[3]: Leaving directory '/tmp/makepkg/gcc44/src/gcc-4.4.7/build/gcc' Makefile:5142: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/tmp/makepkg/gcc44/src/gcc-4.4.7/build' Makefile:17112: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/tmp/makepkg/gcc44/src/gcc-4.4.7/build' Makefile:739: recipe for target 'all' failed make: *** [all] Error 2 It seems something related to gcc5, do somebody have this problem too?

xyproto commented on 2013-11-08 15:10 (UTC)

Updated the package and added 'staticlibs' to the options array. Thanks, mauro2.

mauro2 commented on 2013-11-07 22:48 (UTC)

I needed to add 'staticlibs' to options. See https://bbs.archlinux.org/viewtopic.php?pid=1345153

pelluch commented on 2013-05-06 17:41 (UTC)

Nice! Thanks for the work on keeping this package up-to-date and functional, as some software just refuses to update to a new version of gcc.

xyproto commented on 2013-05-06 11:41 (UTC)

Updated the package to enable libgomp.

xyproto commented on 2013-05-05 00:04 (UTC)

pelluch, just leftovers from when I adopted the package, I will look at it.

pelluch commented on 2013-05-04 00:28 (UTC)

Just curious, any reason as to why you use the flag "--disable-libgomp"? This caused a few builds that use omp to fail for me in matlab. Using "--enable-libgomp" works for me, although I have to add rm -rf "$pkgdir/usr/share/info" in the package() function in order to avoid conflicts with the files already there.

xyproto commented on 2013-04-25 17:54 (UTC)

Updated the PKGBUILD, thanks kristianlm2 and progtologist!

progtologist commented on 2013-04-25 14:10 (UTC)

Fix for PKGBUILD is: options=('!libtool' '!buildflags')

commented on 2013-04-23 19:44 (UTC)

I removed the fortify-source in /etc/makepkg.conf and it seems to be working now. I did not edit this file myself, so I guess a lot of people will be hitting this. Don't know how to fix from PKGBUILD, though. --- /etc/makepkg.conf +++ #<buffer makepkg.conf> @@ -29,7 +29,7 @@ -CPPFLAGS="-D_FORTIFY_SOURCE=2" +CPPFLAGS=""

xyproto commented on 2013-04-15 14:52 (UTC)

If someone is desperate to compile gcc44, it might work if gcc45 or gcc46 is used to compile it with, as a workaround.

xyproto commented on 2013-04-12 12:50 (UTC)

gcc44 doesn't compile here either. Not entirely sure how to make it compile again.

commented on 2013-04-11 20:12 (UTC)

I have the same problem in either gcc44 or gcc45. I've upgraded my system to gcc48 with some other packages, not sure it is the factor. When I built gcc45, I forced it to include some headers, like limit.h, sys/state.h ...etc in the specified in "configure"(depend on some FLAGS in default, and --enable-language=c,c++ since object C may cause some error). I also downgrade some packages upgraded together with gcc48. It can pass these errors, but it finally failed since no enough space, and I didn't try again since I need gcc44, not gcc45. I try to do the same thing with gcc44, but different configure file...

xyproto commented on 2013-04-11 13:29 (UTC)

Will try to reproduce the problem.

tritonas00 commented on 2013-04-11 13:18 (UTC)

same problem here, as urys

xyproto commented on 2013-04-09 20:14 (UTC)

urys, do you have weird CFLAGS or CXXFLAGS? Have you edited /etc/makepkg.conf?

commented on 2013-04-09 15:28 (UTC)

../../libiberty/fibheap.c: In function ‘fibheap_delete_node’: ../../libiberty/fibheap.c:38:24: error: ‘LONG_MIN’ undeclared (first use in this function) #define FIBHEAPKEY_MIN LONG_MIN ^ ../../libiberty/fibheap.c:258:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’ fibheap_replace_key (heap, node, FIBHEAPKEY_MIN); ^ ../../libiberty/fibheap.c:38:24: note: each undeclared identifier is reported only once for each function it appears in #define FIBHEAPKEY_MIN LONG_MIN ^ ../../libiberty/fibheap.c:258:36: note: in expansion of macro ‘FIBHEAPKEY_MIN’ fibheap_replace_key (heap, node, FIBHEAPKEY_MIN); ^ ../../libiberty/fibheap.c: In function ‘fibheap_delete’: ../../libiberty/fibheap.c:269:5: warning: incompatible implicit declaration of b../../libiberty/fibheap.c:360:3: warning: incompatible implicit declaration of uilt-in function ‘memset’ [enabled by default] make[3]: *** [fibheap.o] Error 1 make[3]: Leaving directory `/tmp/yaourt-tmp-urys/aur-gcc44/src/gcc-4.4.7/build/ ibiberty' make[2]: *** [all-stage1-libiberty] Error 2 make[2]: Leaving directory `/tmp/yaourt-tmp-urys/aur-gcc44/src/gcc-4.4.7/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-urys/aur-gcc44/src/gcc-4.4.7/build' make: *** [all] Error 2 what's wrong?

xyproto commented on 2013-03-25 13:26 (UTC)

Thank you, ReedWood. Updated the package to depend on elfutils instead.

ReedWood commented on 2013-03-25 12:07 (UTC)

libelf is not available in the aur. Installing elfutils and removing libelf from the dependency array in the packagebuild of gcc44 solved it for me. If this is the correct fix, please update the package.

GordonGR commented on 2013-03-18 13:10 (UTC)

That would make sense, but no. I generally use aurinstaller unless something wrong (or unless it's a heavy build) in which case I do it manually.

gnloch commented on 2013-03-18 10:16 (UTC)

@GordonGR Are you building with yaourt? It uses the /tmp, which usually is limited to 2.1GB

GordonGR commented on 2013-03-17 01:09 (UTC)

It took two full hours, but it completed successfully with the use of one thread. I guess it is a memory issue after all. I'll run a memcheck. Thank you!

xyproto commented on 2013-03-16 22:11 (UTC)

Does it work if you build it with "make -j1" instead of just "make"? This uses only one thread and much less memory, if should be a memory issue. It's worth a shot? It will take ages to compile, though.

GordonGR commented on 2013-03-16 22:05 (UTC)

It is. I can build all kind of programs, apart from gcc. I will reinstall base-devel and run a memory check tomorrow, for good measure, but I seriously doubt that's the issue. Thanks for looking into it, in any case.

xyproto commented on 2013-03-16 22:01 (UTC)

And base-devel is installed too? Are you able to test it on a different installation?

GordonGR commented on 2013-03-16 21:53 (UTC)

I doubt it. Just to be sure, I rebooted to a clean session, opened a console and nothing else and ran makepkg. It failed to the same point.

xyproto commented on 2013-03-16 15:27 (UTC)

GordanGR, are you out of memory?

GordonGR commented on 2013-03-16 13:56 (UTC)

Not building for me -- log here: https://dl.dropbox.com/u/4361965/gcc44-4.4.7-2-x86_64-build.log I think it's the same problem I have with gcc44 multilib, by the way. Both packages used to build fine until some time ago, I can't understand :S

xyproto commented on 2013-03-15 10:57 (UTC)

Thank you, vladmihaisima. Updated the package.

commented on 2013-03-14 22:46 (UTC)

With texinfo 5.0-1 it fails with the following error: if [ xinfo = xinfo ]; then \ makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --no-split -I . -I ../../gcc/doc \ -I ../../gcc/doc/include -o doc/cpp.info ../../gcc/doc/cpp.texi; \ fi ../../gcc/doc/cppopts.texi:761: @itemx must follow @item make[3]: *** [doc/cpp.info] Error 1 Workaround (will not generate some docs): - add the following line in the PKGBUILD before configure (currently line 43) sed -i 's/BUILD_INFO=info/BUILD_INFO=/' ../gcc/configure - comment or remove the for loop in package() (currently lines 70-73)

xyproto commented on 2012-11-14 01:39 (UTC)

Updated to 4.4.7.

xyproto commented on 2012-02-26 14:43 (UTC)

TamCore, works fine here. Have you installed base-devel first? https://wiki.archlinux.org/index.php/Arch_User_Repository#Getting_started Are all packages up to date?

TamCore commented on 2012-02-26 11:38 (UTC)

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libstdc++.a when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-unknown-linux-gnu/4.4.6/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc When compiling an 32bit project. Any suggestions?

xyproto commented on 2012-02-12 16:42 (UTC)

Updated to gcc 4.4.6.

xyproto commented on 2011-12-02 15:54 (UTC)

Since this package has been an orphan for three weeks now, I'll adopt it.

xyproto commented on 2011-11-10 12:57 (UTC)

This package has been flagged out of date from 22 Feb 2011 to 10 Nov 2011. Fixed the PKGBUILD and orphaned the package. Sincerely yours, a random TU.

xyproto commented on 2011-11-10 12:28 (UTC)

Please depend on cloog instead of cloog-ppl>=0.15.8

commented on 2011-11-05 18:40 (UTC)

Moreover: [herbert@myhost ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.6.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --enable-multilib --disable-libssp --disable-libstdcxx-pch --enable-checking=release Thread model: posix gcc version 4.6.2 (GCC) [herbert@myhost ~]$ gcc-4.4 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib --program-suffix=-4.4 --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++ --enable-__cxa_atexit --disable-libstdcxx-pch --disable-multilib --disable-libgomp --disable-libmudflap --disable-libssp --enable-clocale=gnu --with-tune=generic --with-cloog --with-ppl --with-system-zlib Thread model: posix gcc version 4.4.4 (GCC) [herbert@myhost ~]$ So obviously I have gcc 4.4 -- which I didn't have before -- now, and I also have 4.6.

commented on 2011-11-05 18:37 (UTC)

I was stupid enough to close the terminal in which makepkg was compiling, so I couldn't check if it compiled correctly. Anyhow, pacman seemed to think so: [herbert@durk gcc44]$ sudo pacman -U gcc44-4.4.4-2-x86_64.pkg.tar.xz Password: resolving dependencies... looking for inter-conflicts... Targets (1): gcc44-4.4.4-2 Total Download Size: 0.00 MB Total Installed Size: 65.60 MB Proceed with installation? [Y/n] Y (1/1) checking package integrity [############################################################################] 100% (1/1) checking for file conflicts [############################################################################] 100% (1/1) installing gcc44 [############################################################################] 100% [herbert@durk gcc44]$ So removing the dependency seems to work PLEASE NOTE: THIS IS NOT FROM ANYONE WHO IS IN ANYWAY OFFICIALLY ASSOCIATED WITH ARCH OR AUR! I AM JUST AN ARCH-USER.

commented on 2011-11-05 17:43 (UTC)

I could not find anything like cloog-ppl either. I have cloog from the community supported repo's installed: [root@durk herbert]# pacman -Ss cloog core/cloog 0.16.3-1 [installed] Library that generates loops for scanning polyhedra [root@durk herbert]# To install gcc44, I removed the 'cloog-ppl>=0.15.8' entry from 'depends' variable in the PKGBUILD-file, and makepkg is compiling it now. No errors so far. Could someone from the (arch intersect gcc)-community have a look at this? Thank you very much for reading and I will get back on whether makepkg compiled gcc44 successfully!

mrbit commented on 2011-10-28 17:57 (UTC)

cloog-ppl ???????????????

unknown commented on 2011-09-16 07:43 (UTC)

Please orphan so we can update the pkgbuild ourselves.

commented on 2011-07-03 08:47 (UTC)

I have large problems installing this. I removed the --disable-libgomp flag, as I need OpenMP, but I get the error: Configuring stage 2 in ./intl configure: creating cache ./config.cache checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... /bin/install -c checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for x86_64-unknown-linux-gnu-gcc... /tmp/yaourt-tmp-martin/aur-gcc44/src/gcc-4.4.4/build/./prev-gcc/xgcc -B/tmp/yaourt-tmp-martin/aur-gcc44/src/gcc-4.4.4/build/./prev-gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ checking for C compiler default output file name... configure: error: in `/tmp/yaourt-tmp-martin/aur-gcc44/src/gcc-4.4.4/build/intl': configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage2-intl] Error 77 make[2]: Leaving directory `/tmp/yaourt-tmp-martin/aur-gcc44/src/gcc-4.4.4/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-martin/aur-gcc44/src/gcc-4.4.4/build' make: *** [all] Error 2 ======================================================================================== The config.log from the intl folder can be found on: http://pastebin.com/zXS2xYPR My guess is that the host=x86_64-unkown-linux-gnu might be the problem, but have no idea how to fix it. I also get the exact same error without removing the -disable-libgomp flag, or trying to compiler gcc43 from aur.

commented on 2011-06-16 15:13 (UTC)

Yes, this works fine by just changing the depend from 'cloog-ppl' to 'cloog' in the PKGBUILD

commented on 2011-06-14 23:03 (UTC)

you can just use cloog from core http://www.archlinux.org/packages/core/x86_64/cloog/

Void-995 commented on 2011-06-08 16:21 (UTC)

It works well without cloog-ppl (with little tricks around PKGBUILD), but it would be better if cloog-ppl become avaible on AUR.

sl1pkn07 commented on 2011-04-22 22:39 (UTC)

cloog-ppl not longer available on AUR

Barthalion commented on 2011-03-19 09:28 (UTC)

For you maybe yes, but newest version (4.5) have much worst performance and optimization, and I'm using this to compiling everything.

commented on 2011-03-01 10:21 (UTC)

I guess we need to see what gcc is needed for the new cuda-sdk 4.0 before anything else.

sl1pkn07 commented on 2011-02-23 00:48 (UTC)

barthalion. this is for cuda-sdk. only compile with this

Barthalion commented on 2011-02-22 11:34 (UTC)

4.4.5 was released 4 months ago.

Xaap commented on 2010-08-24 23:37 (UTC)

It worked perfectly for me. Thanks

commented on 2010-07-09 15:12 (UTC)

Not building on my machine with the message: lib/libppl_c.so: undefined reference to `std::ctype<char>::_M_widen_init() const@GLIBCXX_3.4.11