gcc downgrade

Raccoon1400 · 2008-05-14 20:20:07

I am tired of gcc 4.3 failing to compile packages. I tried to downgrade to 4.2 and I get this.

[root@myhost Desktop]# pacman -U ./gcc-4.2.1-3.pkg.tar.gz
loading package data...
checking dependencies...
(1/1) checking for file conflicts                   [#####################] 100%
error: failed to prepare transaction (conflicting files)
gcc: /usr/lib/libgcc_s.so exists in filesystem
gcc: /usr/lib/libgcc_s.so.1 exists in filesystem
gcc: /usr/lib/libgomp.a exists in filesystem
gcc: /usr/lib/libgomp.so exists in filesystem
gcc: /usr/lib/libgomp.so.1 exists in filesystem
gcc: /usr/lib/libgomp.so.1.0.0 exists in filesystem
gcc: /usr/lib/libgomp.spec exists in filesystem
gcc: /usr/lib/libmudflap.a exists in filesystem
gcc: /usr/lib/libmudflap.so exists in filesystem
gcc: /usr/lib/libmudflap.so.0 exists in filesystem
gcc: /usr/lib/libmudflap.so.0.0.0 exists in filesystem
gcc: /usr/lib/libmudflapth.a exists in filesystem
gcc: /usr/lib/libmudflapth.so exists in filesystem
gcc: /usr/lib/libmudflapth.so.0 exists in filesystem
gcc: /usr/lib/libmudflapth.so.0.0.0 exists in filesystem
gcc: /usr/lib/libobjc.a exists in filesystem
gcc: /usr/lib/libobjc.so exists in filesystem
gcc: /usr/lib/libobjc.so.2 exists in filesystem
gcc: /usr/lib/libobjc.so.2.0.0 exists in filesystem
gcc: /usr/lib/libssp.a exists in filesystem
gcc: /usr/lib/libssp.so exists in filesystem
gcc: /usr/lib/libssp.so.0 exists in filesystem
gcc: /usr/lib/libssp.so.0.0.0 exists in filesystem
gcc: /usr/lib/libssp_nonshared.a exists in filesystem
gcc: /usr/lib/libstdc++.a exists in filesystem
gcc: /usr/lib/libstdc++.so exists in filesystem
gcc: /usr/lib/libstdc++.so.6 exists in filesystem
gcc: /usr/lib/libsupc++.a exists in filesystem
gcc: /usr/share/locale/de/LC_MESSAGES/libstdc++.mo exists in filesystem
gcc: /usr/share/locale/fr/LC_MESSAGES/libstdc++.mo exists in filesystem

errors occurred, no packages were upgraded.
[root@myhost Desktop]#

tomk · 2008-05-14 20:47:12

You've gone back to before we split gcc-libs out of the main gcc package, so that's what you're seeing here. pacman -R gcc-libs will sort you out, or you could use a later gcc package with the corresponding gcc-libs package.

Raccoon1400 · 2008-05-14 21:05:20

I get this. Is there a more recent 4.2 package?

[root@myhost Desktop]# pacman -R gcc-libs
loading package data...
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: agg: requires gcc-libs
:: aspell: requires gcc-libs
:: cairomm: requires gcc-libs>=4.3.0
:: cdrdao: requires gcc-libs
:: cmake: requires gcc-libs>=4.0.3
:: codecs: requires gcc-libs
:: csup: requires gcc-libs
:: db: requires gcc-libs
:: db4.1: requires gcc-libs
:: dvd+rw-tools: requires gcc-libs
:: exempi: requires gcc-libs>=4.3.0
:: exiv2: requires gcc-libs
:: fam: requires gcc-libs
:: firefox3: requires gcc-libs
:: fltk: requires gcc-libs
:: fluxbox: requires gcc-libs
:: gc: requires gcc-libs
:: gcc: requires gcc-libs>=4.3.0
:: gettext: requires gcc-libs
:: gmp: requires gcc-libs
:: gnutls: requires gcc-libs
:: groff: requires gcc-libs
:: gstreamer0.10-bad: requires gcc-libs>=4.3.0
:: hunspell: requires gcc-libs
:: imagemagick: requires gcc-libs
:: libcdio: requires gcc-libs>=4.3.0
:: libsigc++2.0: requires gcc-libs>=4.3.0
:: libsmbios: requires gcc-libs>=4.3.0
:: libstdc++5: requires gcc-libs
:: libusb: requires gcc-libs
:: maelstrom: requires gcc-libs
:: mesa: requires gcc-libs
:: pacman: requires gcc-libs
:: pcre: requires gcc-libs
:: plotutils: requires gcc-libs
:: poppler: requires gcc-libs>=4.3.0
:: pstoedit: requires gcc-libs>=4.2.1
:: rarian: requires gcc-libs
:: taglib: requires gcc-libs
:: unrar: requires gcc-libs
:: xulrunner: requires gcc-libs>=4.3.0

Last edited by Raccoon1400 (2008-05-14 21:05:33)

pressh · 2008-05-14 21:38:24

gcc 4.2.3: http://shellpenguin.com/arch/pkg/

though that will still give problems for packages requiring gcc-libs>=4.3.0

Why can't you use gcc 3.4 which is also in the repos to compile packages that don't compile with gcc 4.3 ?

Raccoon1400 · 2008-05-14 22:06:50

pressh wrote:

gcc 4.2.3: http://shellpenguin.com/arch/pkg/
though that will still give problems for packages requiring gcc-libs>=4.3.0
Why can't you use gcc 3.4 which is also in the repos to compile packages that don't compile with gcc 4.3 ?

It would be simpler to stick to one compiler. It seems about half the packages I tried to compile failed to build.

dolby · 2008-05-14 22:30:00

there are patches available for most if not all applications across the web. you might have better luck sticking with 4.3 and applying the patches

Raccoon1400 · 2008-05-14 23:17:10

dolby wrote:

there are patches available for most if not all applications across the web. you might have better luck sticking with 4.3 and applying the patches

I still don't want to have to hunt around the web to compile an app. What did they do to gcc that caused this to happen?

dolby · 2008-05-15 05:33:23

Belive it or not, they fixed it

zyghom · 2008-05-15 09:10:16

dolby wrote:

there are patches available for most if not all applications across the web. you might have better luck sticking with 4.3 and applying the patches

not for kmymoney2 0.9 :-(

Raccoon1400 · 2008-05-16 20:18:19

Can I compile 64 bit packages on the 32 bit debian machine beside me?

tomk · 2008-05-16 21:25:35

No

Raccoon1400 · 2008-05-17 22:54:05

pressh wrote:

gcc 4.2.3: http://shellpenguin.com/arch/pkg/
though that will still give problems for packages requiring gcc-libs>=4.3.0
Why can't you use gcc 3.4 which is also in the repos to compile packages that don't compile with gcc 4.3 ?

Okay, but how do I tell it to use 3.4 instead of 4.3?

pressh · 2008-05-18 06:46:16

Raccoon1400 wrote:

Okay, but how do I tell it to use 3.4 instead of 4.3?

For most packages, replacing

./configure --prefix=/usr
make || return 1
make DESTDIR=$startdir/pkg install || return 1

in the build function of the PKGBUILD by something similar to

if [ "$CARCH" == "x86_64" ]; then
  export CFLAGS="-march=x86-64 -mtune=x86-64 -O2 -pipe"
  export CXXFLAGS="-march=x86-64 -mtune=x86-64 -O2 -pipe"
else
  export CFLAGS="-march=$CARCH -mtune=$CARCH -O2 -pipe"
  export CXXFLAGS="-march=$CARCH -mtune=$CARCH -O2 -pipe"
fi

./configure CC=gcc-3.4 HOSTCC=gcc-3.4 CXX=g++-3.4 --prefix=/usr
  make CC=gcc-3.4 HOSTCC=gcc-3.4 CXX=g++-3.4 || return 1
  make DESTDIR=${startdir}/pkg install || return 1

should do the trick.

For packages using cmake for configuring, replacing

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release .

by something similar to

  CC=gcc-3.4 HOSTCC=gcc-3.4 CXX=g++-3.4 cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release .

should do the trick. Note that you still need to export the CFLAGS and CXXFLAGS and the 'make' line as in the first example.

For packages using yet another configuring you should be able to do something more or less similar to the above examples.

shining · 2008-05-18 09:51:03

To pressh:
Why do you need to redefine the cflags in the pkgbuild? They are already defined in makepkg.conf.

To OP:
You should really try to get your app compile with 4.3. At the very least submit your build troubles to upstream developers so that they can fix it.
If you can patch the app yourself and submit them directly the patch, it's even better. You will also be able to use your own patch in the meantime.

pressh · 2008-05-19 08:02:06

shining wrote:

To pressh:
Why do you need to redefine the cflags in the pkgbuild? They are already defined in makepkg.conf.

for i686 you can indeed just use the ones defined in makepkg.conf, which it actually does because you export the same. You could of course export nothing and get the same result.

For x86_64 however, the CFLAGS are named differently to what the gcc4 understands. Note the difference between x86-64 and x86_64. Not exporting the CFLAGS for x86_64 will most likely fail the build.

zyghom · 2008-05-19 10:07:34

thank you pressh, this did the trick for kmymoney2 from svn

Raccoon1400 · 2008-05-19 20:46:22

How can I fix gperiodic?

gcc -c `pkg-config --cflags gtk+-2.0` -I. -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED  gperiodic.c
In file included from gperiodic.c:37:
gperiodic.h:73: error: expected specifier-qualifier-list before 'GtkTooltips'
gperiodic.c: In function 'gpparse_print_element_data_for_num':
gperiodic.c:76: warning: cast from pointer to integer of different size
gperiodic.c: In function 'main_prog':
gperiodic.c:389: error: 'struct table_entry' has no member named 'tooltip'
gperiodic.c:390: error: 'struct table_entry' has no member named 'tooltip'
gperiodic.c:391: error: 'struct table_entry' has no member named 'tooltip'
make: *** [gperiodic.o] Error 1
==> ERROR: Build Failed.
    Aborting...
[duncan@myhost PT]$

pkgname=gperiodic
pkgver=2.0.10
pkgrel=1
pkgdesc="GPeriodic is a program for looking up data of elements from the periodic table."
arch=('x86_64')
url="http://koti.welho.com/jfrantz/software/gperiodic.html"
license=""
depends=('x-server' 'gtk2')
makedepends=()
conflicts=()
replaces=()
backup=()
install=
source=(http://koti.welho.com/jfrantz/software/$pkgname-$pkgver.tar.gz)
md5sums=('9680f8a4850bdafad113fd4af7c57e45')

build() {
  cd $startdir/src/$pkgname-$pkgver

    #Write our own makefile, theirs was no good
  cat > Makefile << "EOF"
CC=gcc
CFLAGS=`pkg-config --cflags gtk+-2.0` -I. -DG_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED
LIBS=`pkg-config --libs gtk+-2.0`
bindir ?= /usr/bin
datadir ?= /usr/share

.c.o:
    $(CC) -c $(CFLAGS) $(CPPFLAGS) $<

gperiodic: gperiodic.o
    $(CC) $(CFLAGS) -o gperiodic gperiodic.o $(LIBS)
    strip gperiodic

gpdata.o: gpdata.c gperiodic.h

gperiodic.o: gperiodic.c gperiodic.h table_data.h

install:
    make -C po/ install enable_nls=1 datadir=$(datadir)
    install -D gperiodic $(INSTALL_PREFIX)$(bindir)/gperiodic
    install -D gperiodic.desktop $(INSTALL_PREFIX)$(datadir)/applications/gperiodic.desktop
    install -D gperiodic.png $(INSTALL_PREFIX)$(datadir)/pixmaps/gperiodic.png
    install -D gperiodic-crystal.png $(INSTALL_PREFIX)$(datadir)/pixmaps/gperiodic-crystal.png
    make clean

uninstall:
    rm $(INSTALL_PREFIX)$(bindir)/gperiodic

clean:
    - rm *.o gperiodic
    - rm po/*.mo
EOF

  make || return 1
  make INSTALL_PREFIX=$startdir/pkg install
}
# vim: ft=sh ts=2

pressh · 2008-05-19 21:51:02

Raccoon1400 wrote:

How can I fix gperiodic?

wow, that must be one of the worst PKGBUILDs in Archs history
I just orphaned all the user's package as he seems not to be around anymore, so feel free to adopt it and maintain it.

You can use this PKGBUILD for gperiodic

pkgname=gperiodic
pkgver=2.0.10
pkgrel=1
pkgdesc="GPeriodic is a program for looking up data of elements from the periodic table"
url="http://www.frantz.fi/software/gperiodic.php"
license=('GPL')
depends=('gtk2')
arch=('i686' 'x86_64')
source=(http://www.frantz.fi/software/$pkgname-$pkgver.tar.gz)
md5sums=('9680f8a4850bdafad113fd4af7c57e45')

build() {
  cd $startdir/src/$pkgname-$pkgver

  # dirty trick to build
  # please create a patch and submit upstream
  # see: http://library.gnome.org/devel/gtk/unstable/gtk-migrating-tooltips.html
  # for more details
  sed -i 's;-DGTK_DISABLE_DEPRECATED;;' Makefile

  make || return 1
  make DESTDIR=$startdir/pkg install || return 1
}

[edit] fixed end quotes in url (damn you copying )

Last edited by pressh (2008-05-19 22:53:23)

Raccoon1400 · 2008-05-19 22:40:49

Thanks pressh. That worked. Only you missed the closing quote on line 4.
I'll adopt the package and fix the pkgbuild, but with my current knowledge of building packages and PKGBUILDs I can't do much more that upgrade the files to newer versions.

Raccoon1400 · 2008-05-19 22:45:08

One question. I adoped it, but can't figure out how to edit files and details.

pressh · 2008-05-19 22:51:11

Raccoon1400 wrote:

One question. I adoped it, but can't figure out how to edit files and details.

All is explained in the AUR User Guidelines (especially section 2.2 and 2.3 for your current question, but please read all).

Make sure you also read Arch Packaging Standards.

Raccoon1400 wrote:

I'll adopt the package and fix the pkgbuild, but with my current knowledge of building packages and PKGBUILDs I can't do much more that upgrade the files to newer versions.

Well. you have to start somewhere. Learn from trying/doing. All the PKGBUILDs in core/extra/community (and to some extend also AUR) are a great source of examples. If you're really stuck at some time, you can always ask here on bbs for help.

Last edited by pressh (2008-05-19 22:57:07)

Raccoon1400 · 2008-05-21 21:32:21

I was looking at my AUR files and realized way less than half had failed. I fixed another build with instructions someone had posted on it's AUR page.

pressh · 2008-05-21 21:47:17

Raccoon1400 wrote:

I was looking at my AUR files and realized way less than half had failed. I fixed another build with instructions someone had posted on it's AUR page.

don't forget to update the gperiodic package you adopted

If a package needs a fix or is out of date and the maintainer of that package is not around anymore and does not respond if you mail him, you can ask for an orphan request on the aur-general mailing list so you can adopt and fix/update these packages.

shining · 2008-05-21 22:28:53

pressh wrote:

shining wrote:
To pressh:
Why do you need to redefine the cflags in the pkgbuild? They are already defined in makepkg.conf.
for i686 you can indeed just use the ones defined in makepkg.conf, which it actually does because you export the same. You could of course export nothing and get the same result.
For x86_64 however, the CFLAGS are named differently to what the gcc4 understands. Note the difference between x86-64 and x86_64. Not exporting the CFLAGS for x86_64 will most likely fail the build.

Still, I don't understand why you don't simply define directly the correct x86-64 cflags in makepkg.conf, but I am probably missing something..

Raccoon1400 · 2008-05-22 01:50:04

pressh wrote:

don't forget to update the gperiodic package you adopted

Yes, as soon as I figure out how. I did post your pkgbuild as a comment in case anyone else wants to compile it in the meantime.

Arch Linux

#1 2008-05-14 20:20:07

gcc downgrade

#2 2008-05-14 20:47:12

Re: gcc downgrade

#3 2008-05-14 21:05:20

Re: gcc downgrade

#4 2008-05-14 21:38:24

Re: gcc downgrade

#5 2008-05-14 22:06:50

Re: gcc downgrade

#6 2008-05-14 22:30:00

Re: gcc downgrade

#7 2008-05-14 23:17:10

Re: gcc downgrade

#8 2008-05-15 05:33:23

Re: gcc downgrade

#9 2008-05-15 09:10:16

Re: gcc downgrade

#10 2008-05-16 20:18:19

Re: gcc downgrade

#11 2008-05-16 21:25:35

Re: gcc downgrade

#12 2008-05-17 22:54:05

Re: gcc downgrade

#13 2008-05-18 06:46:16

Re: gcc downgrade

#14 2008-05-18 09:51:03

Re: gcc downgrade

#15 2008-05-19 08:02:06

Re: gcc downgrade

#16 2008-05-19 10:07:34

Re: gcc downgrade

#17 2008-05-19 20:46:22

Re: gcc downgrade

#18 2008-05-19 21:51:02

Re: gcc downgrade

#19 2008-05-19 22:40:49

Re: gcc downgrade

#20 2008-05-19 22:45:08

Re: gcc downgrade

#21 2008-05-19 22:51:11

Re: gcc downgrade

#22 2008-05-21 21:32:21

Re: gcc downgrade

#23 2008-05-21 21:47:17

Re: gcc downgrade

#24 2008-05-21 22:28:53

Re: gcc downgrade

#25 2008-05-22 01:50:04

Re: gcc downgrade

Board footer