On Monday 27 July 2009 04:36:52 am Matthias Hopf wrote:

On Jul 25, 09 01:21:13 -0500, David C. Rankin wrote:

...

After taking 2 steps forward in the past couple of updates, looks like we went 3 steps back. On my Toshiba laptop with RS690M (x1200), the latest updates completely prevent X from starting. The bug seems related to Atombios. A summary of the errors and warning from my Xorg.0.log are as follows:

Sigh. I feared that. Can you try git commit 3d031afba8c23b (the previous to the current one) and check whether that one is working correctly?

Thanks

Matthias

Sure, but err, umm... How do I pull a specific commit?? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Wednesday 29 July 2009 07:05:48 am Matthias Hopf wrote:

On Jul 29, 09 00:52:42 -0500, David C. Rankin wrote:

...

On Monday 27 July 2009 04:36:52 am Matthias Hopf wrote:

...

On Jul 25, 09 01:21:13 -0500, David C. Rankin wrote:

...

After taking 2 steps forward in the past couple of updates, looks like we went 3 steps back. On my Toshiba laptop with RS690M (x1200), the latest updates completely prevent X from starting. The bug seems related to Atombios. A summary of the errors and warning from my Xorg.0.log are as follows:

Sigh. I feared that. Can you try git commit 3d031afba8c23b (the previous to the current one) and check whether that one is working correctly?

With a not-too-old git (1.5 should suffice) you can just 'git co 3d031afba8c23b' and are done. Do 'git co master' to get back on track afterwards.

Matthias

Errr! I hate git (or it hates me): 17:29 alchemy:~> cd archlinux/apps/radeonhd/ 17:30 alchemy:~/archlinux/apps/radeonhd> git co 3d031afba8c23b git: 'co' is not a git-command. See 'git --help'. Did you mean one of these? clone log 17:30 alchemy:~/archlinux/apps/radeonhd> pmq git git 1.6.4-1 17:30 alchemy:~/archlinux/apps/radeonhd> git clone 3d031afba8c23b Initialized empty Git repository in /home/david/archlinux/apps/radeonhd/3d031afba8c23b/.git/ warning: You appear to have cloned an empty repository. fatal: The remote end hung up unexpectedly 17:30 alchemy:~/archlinux/apps/radeonhd> git clone 3d031afba8c23b fatal: destination path '3d031afba8c23b' already exists and is not an empty directory. 17:31 alchemy:~/archlinux/apps/radeonhd> l 3d031afba8c23b/ total 12 drwxr-xr-x 3 david david 4096 2009-07-29 17:30 . drwxr-xr-x 8 david david 4096 2009-07-29 17:30 .. drwxr-xr-x 7 david david 4096 2009-07-29 17:30 .git 17:31 alchemy:~/archlinux/apps/radeonhd> l 3d031afba8c23b/.git/ total 40 drwxr-xr-x 7 david david 4096 2009-07-29 17:30 . drwxr-xr-x 3 david david 4096 2009-07-29 17:30 .. drwxr-xr-x 2 david david 4096 2009-07-29 17:30 branches drwxr-xr-x 2 david david 4096 2009-07-29 17:30 hooks drwxr-xr-x 2 david david 4096 2009-07-29 17:30 info drwxr-xr-x 4 david david 4096 2009-07-29 17:30 objects drwxr-xr-x 4 david david 4096 2009-07-29 17:30 refs -rw-r--r-- 1 david david 23 2009-07-29 17:30 HEAD -rw-r--r-- 1 david david 275 2009-07-29 17:30 config -rw-r--r-- 1 david david 73 2009-07-29 17:30 description 17:31 alchemy:~/archlinux/apps/radeonhd> l 3d031afba8c23b/.git/branches/ total 8 drwxr-xr-x 2 david david 4096 2009-07-29 17:30 . drwxr-xr-x 7 david david 4096 2009-07-29 17:30 .. 17:31 alchemy:~/archlinux/apps/radeonhd> rm -r 3d031afba8c23b/ 17:31 alchemy:~/archlinux/apps/radeonhd> git clone 3d031afba8c23b Initialized empty Git repository in /home/david/archlinux/apps/radeonhd/3d031afba8c23b/.git/ warning: You appear to have cloned an empty repository. fatal: The remote end hung up unexpectedly 17:31 alchemy:~/archlinux/apps/radeonhd> rm -r 3d031afba8c23b/ -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Wednesday 29 July 2009 05:41:49 pm you wrote:

2009/7/29 David C. Rankin :

...

On Wednesday 29 July 2009 07:05:48 am Matthias Hopf wrote:

...

On Jul 29, 09 00:52:42 -0500, David C. Rankin wrote:

...

On Monday 27 July 2009 04:36:52 am Matthias Hopf wrote:

...

Can you try git commit 3d031afba8c23b (the previous to the current one) and check whether that one is working correctly?

With a not-too-old git (1.5 should suffice) you can just 'git co 3d031afba8c23b' and are done. Do 'git co master' to get back on track afterwards.

Errr! I hate git (or it hates me):

17:29 alchemy:~> cd archlinux/apps/radeonhd/ 17:30 alchemy:~/archlinux/apps/radeonhd> git co 3d031afba8c23b git: 'co' is not a git-command. See 'git --help'.

"co" is a subversion shortcut. You want

git checkout 3d031afba8c23b

;)

Cheers,

Thanks, I'll pull it now -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

2009/7/29 David C. Rankin :

On Wednesday 29 July 2009 05:41:49 pm Yang Zhao wrote:

...

2009/7/29 David C. Rankin :

...

On Wednesday 29 July 2009 07:05:48 am Matthias Hopf wrote:

...

On Jul 29, 09 00:52:42 -0500, David C. Rankin wrote:

...

On Monday 27 July 2009 04:36:52 am Matthias Hopf wrote:

...

Can you try git commit 3d031afba8c23b (the previous to the current one) and check whether that one is working correctly?

With a not-too-old git (1.5 should suffice) you can just 'git co 3d031afba8c23b' and are done. Do 'git co master' to get back on track afterwards.

Errr! I hate git (or it hates me):

17:29 alchemy:~> cd archlinux/apps/radeonhd/ 17:30 alchemy:~/archlinux/apps/radeonhd> git co 3d031afba8c23b git: 'co' is not a git-command. See 'git --help'.

"co" is a subversion shortcut. You want

  git checkout 3d031afba8c23b

;)

Cheers,

Err, Yang, I'm still having problems:

17:53 alchemy:~/archlinux/apps/radeonhd> git checkout 3d031afba8c23b Note: moving to '3d031afba8c23b' which isn't a local branch If you want to create a new branch from this checkout, you may do so (now or later) by using -b with the checkout command again. Example:  git checkout -b HEAD is now at 3d031af... Validate current clocks - some AtomBIOSes provide broken values. 17:53 alchemy:~/archlinux/apps/radeonhd> ./dcrinst

       Configuring:  ./autogen.sh --prefix=/usr

autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext

<snip>

       Executing: sudo make install

Making install in src fatal: ref HEAD is not a symbolic ref git_version.sh: Output is unchanged, keeping git_version.h radeon(4) man page is current. README file is current.  /bin/sh /home/david/archlinux/apps/radeonhd/./shave-libtool '/bin/sh ../libtool'   --mode=install /bin/install -c   radeonhd_drv.la '/usr/lib/xorg/modules/drivers'

Making install in man  /bin/install -c -m 644 radeonhd.4 '/usr/share/man/man4' Making install in utils/conntest fatal: ref HEAD is not a symbolic ref git_version.sh: Output is unchanged, keeping git_version.h

I'm under the impression that it should build and install the module regardless. If that's not working, checkout the particular commit as its own branch, which should work: git checkout -b test 3d031afba8c23b -- Yang Zhao http://yangman.ca -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Доброе время суток, David C. Rankin.

# Driver "radeon" Driver "radeonhd"

Then attempted to restart kdm - no joy. Same problem as last time, the screen goes black and just gets stuck. ctrl+alt+f1 required to regain a terminal, kill kdm, change back to the radeon driver and restart. I've attached the logs.

if Driver "radeonhd" Option "DRI" "off" X Server start? The card is agp? -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Jul 29, 09 23:25:43 -0500, David C. Rankin wrote:

Up until a week ago, this card ran good with the radeonhd driver from the git repository. The recent Atmbios changes caused the problem. Matthias has a good idea what changes caused the issue. I have tried whatever the status of the changes in:

git checkout 3d031afba8c23b

In that case I don't have a good idea any more. Could you git-bisect this? You said you had a working version a week ago, so do a git checkout de3f80bc6ec and check whether it works. If it does, do a git bisect start 3d031afba8c23b de3f80bc6ec (i.e. git bisect start <bad> <good>). This will get you another version to compile and test. If it works, do a 'git bisect good', otherwise a 'git bisect bad'. In the end you will get a single revision that introduced the bug, and that's what we need. CU Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Wednesday 29 July 2009 07:05:48 am Matthias Hopf wrote:

On Jul 29, 09 00:52:42 -0500, David C. Rankin wrote:

...

On Monday 27 July 2009 04:36:52 am Matthias Hopf wrote:

...

On Jul 25, 09 01:21:13 -0500, David C. Rankin wrote:

...

After taking 2 steps forward in the past couple of updates, looks like we went 3 steps back. On my Toshiba laptop with RS690M (x1200), the latest updates completely prevent X from starting. The bug seems related to Atombios. A summary of the errors and warning from my Xorg.0.log are as follows:

Sigh. I feared that. Can you try git commit 3d031afba8c23b (the previous to the current one) and check whether that one is working correctly?

With a not-too-old git (1.5 should suffice) you can just 'git co 3d031afba8c23b' and are done. Do 'git co master' to get back on track afterwards.

Matthias

Matthais, Now the autogen script fails: autoreconf: running: /usr/bin/autoconf configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 Reading the install, I confirmed I have had all the macro packages installed that I have always had installed for archlinux: m4 1.4.13-1 xorg-util-macros 1.2.2-1 which provide: xorg-macros.m4 xorg-server.m4, but not xorgversion.m4 I have always been able to build successfully build radeonhd, so I'm wondering what changed. I did just pull a new copy of the git repository so if I had any additional links in there, those may have been lost. Any ideas? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Thursday 30 July 2009 05:32:30 am Matthias Hopf wrote:

On Jul 30, 09 01:50:39 -0500, David C. Rankin wrote:

...

Now the autogen script fails:

autoreconf: running: /usr/bin/autoconf configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1

Please try running autoconf, not autoreconf. I remember that there was an issue, but I don't remember the details. I think it has to do with the installed autoconf version. If some autoconf guru could check our configure.ac, I would be delighted...

...

xorg-util-macros 1.2.2-1

That is the most recent version.

Matthias

Matthias, Here is where I am. The autogen.sh is failing. I got so frustrated the just removed the radeonhd directory and started over with a freash . But with a brand new retreival of the repository, autogen complains: 09:19 alchemy:~/archlinux/apps/radeonhd> sh autogen.sh --prefix=/usr autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoreconf: running: /usr/bin/autoconf configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 Comparing the INSTALL notes to what I have, the only m4 marcro I don't have is the xorgversion.m4. According to the archlinux folks, xorgversion.m4 is deprecated (for over a year) so I don't think that is the problem.[footnote 1] In this partticular case, autoconf is failing on "_m4_text_wrap_word". I don't know how to work around this. It's frustrating to have been able to build the driver without issue for the past 6 months to now be unable to do "step 1" in the configure process. I have never had a problem with "sh autogen.sh --prefix=/usr". What am I missing? [footnote 1] On Thu, 2009-07-30 at 00:44 -0500, David C. Rankin wrote:

Listmates,

I can't build the radeonhd driver any longer due to a missing xorgversion.m4. I have both

m4 1.4.13-1 xorg-util-macros 1.2.2-1

installed but I can't find the xorgversion file. Any ideas?

That file is deprecated: # Previous versions used to install xorgversion.m4, now integrated # into xorg-macros.m4. Explicitly remove that old file in order not # to have a macro defined in two different files. install-data-hook: rm -f $(DESTDIR)$(aclocaldir)/xorgversion.m4 http://cgit.freedesktop.org/xorg/util/macros/commit/?id=b8a5186c585b4f019714... This has been changed a year ago, so I guess you're trying to compile something very old. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Thursday 30 July 2009 10:24:33 am Matthias Hopf wrote:

On Jul 30, 09 09:35:21 -0500, David C. Rankin wrote:

...

...

...

autoreconf: /usr/bin/autoconf failed with exit status: 1

Please try running autoconf, not autoreconf. I remember that there was an issue, but I don't remember the details. I think it has to do with the installed autoconf version. If some autoconf guru could check our configure.ac, I would be delighted... Here is where I am. The autogen.sh is failing. I got so frustrated the just removed the radeonhd directory and started over with a freash . But with a brand new retreival of the repository, autogen complains:

Something in the autoreconf run doesn't work. I had this here as well, but as I cannot reproduce any more I cannot easily fix this.

Can you try to exchange autoreconf -v --install by autoreconf -v -f -i

in autogen.sh and try again?

With "autoreconf -v -f -i || exit 1" 09:48 alchemy:~/archlinux/apps/radeonhd> sh autogen-autoconf.sh --prefix=/usr autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./ltmain.sh' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal autoreconf: running: /usr/bin/autoconf --force configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1

If this still fails I'm a bit lost why autoreconf doesn't work, and don't have to time to dig into this. But if it still fails, try running autoconf -f autoheader -f aclocal -f automake -f and you should be good to ./configure and make.

11:02 alchemy:~/archlinux/apps/radeonhd> autoconf -f configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. 11:03 alchemy:~/archlinux/apps/radeonhd> autoheader -f 11:04 alchemy:~/archlinux/apps/radeonhd> aclocal -f aclocal: unrecognized option `-f' aclocal: Try `/usr/bin/aclocal --help' for more information. 11:04 alchemy:~/archlinux/apps/radeonhd> automake -f configure.ac:44: required file `./config.guess' not found configure.ac:44: `automake --add-missing' can install `config.guess' configure.ac:44: required file `./config.sub' not found configure.ac:44: `automake --add-missing' can install `config.sub' configure.ac:13: required file `./install-sh' not found configure.ac:13: `automake --add-missing' can install `install-sh' configure.ac:13: required file `./missing' not found configure.ac:13: `automake --add-missing' can install `missing' src/Makefile.am: required file `./depcomp' not found src/Makefile.am: `automake --add-missing' can install `depcomp' This looks bad....

What autoconf version are you using? Have you changed that recently?

11:04 alchemy:~/archlinux/apps/radeonhd> pmq autoconf autoconf 2.64-1 -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

On Thursday 30 July 2009 12:04:00 pm Matthias Hopf wrote:

On Jul 30, 09 11:06:02 -0500, David C. Rankin wrote:

...

autoreconf: running: /usr/bin/autoconf --force configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation.

I googled and found one other source for this error. This went away with autoconf 2.63, which is also the version I'm using.

...

11:04 alchemy:~/archlinux/apps/radeonhd> pmq autoconf autoconf 2.64-1

As a potential workaround, can you install 2.63 and try again? Sorry, but I'm really fishing in the dark here...

You could also grep for m4_text_wrap_word in /usr/share/aclocal and /usr/share/auto*

I don't have this anywhere here. Apparently, this is a macro that had been added to m4sugar.m4. But I don't see any use of it...

Matthias

Negative on both accounts: [14:35 alchemy:~/.ssh] # grep m4_text_wrap_word /usr/share/aclocal/* [14:54 alchemy:~/.ssh] # grep m4_text_wrap_word /usr/share/auto* I also confirmed this problem on another archilinux box that had never had the radeonhd git repository on it before. After cloning the repository and attempting autogen, I got the same result. autogen failed with the same error. I guess that is the downside to using all the "auto" stuff. A bug or change in the automated tools has the same result as a fatal bug in the radeonhd code itself. Either way, the driver cannot be built. I'll check with archlinux and see if I can find autoconf 2.6.3 and see if that helps. The only place m4_text_wrap_word appears is in the "configure" that is being produced for the radeonhd driver. If the radeonhd driver doesn't use it, then why is it here causing problems?? 15:04 alchemy:~/archlinux/apps/radeonhd> grep -r m4_text_wrap_word * autom4te.cache/output.0: [default], [ ], [79])[][]_m4_text_wrap_word([enabled] autom4te.cache/output.0: [default], [ ], [79])[][]_m4_text_wrap_word([enabled] autom4te.cache/output.1: [default], [ ], [79])[][]_m4_text_wrap_word([enabled] autom4te.cache/output.1: [default], [ ], [79])[][]_m4_text_wrap_word([enabled] configure: [default], [ ], [79])[][]_m4_text_wrap_word([enabled] configure: [default], [ ], [79])[][]_m4_text_wrap_word([enabled] -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

GS Hunt schrieb:

David C. Rankin wrote:

...

On Thursday 30 July 2009 12:04:00 pm Matthias Hopf wrote:

...

On Jul 30, 09 11:06:02 -0500, David C. Rankin wrote:

...

autoreconf: running: /usr/bin/autoconf --force configure:1583: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. I googled and found one other source for this error. This went away with autoconf 2.63, which is also the version I'm using.

...

11:04 alchemy:~/archlinux/apps/radeonhd> pmq autoconf autoconf 2.64-1 As a potential workaround, can you install 2.63 and try again? Sorry, but I'm really fishing in the dark here...

You could also grep for m4_text_wrap_word in /usr/share/aclocal and /usr/share/auto*

I don't have this anywhere here. Apparently, this is a macro that had been added to m4sugar.m4. But I don't see any use of it...

Matthias

Have you installed/reinstalled Arch's base-devel group of development tools?

Gary

For me it works again, with the attached patch to configure.ac . Jens

Matthias Hopf schrieb:

On Jul 31, 09 16:16:07 +0200, Jens Lody wrote:

...

For me it works again, with the attached patch to configure.ac .

Hm. This doesn't sound like it. Can you revert the change and try again? Then it is some caching behavior that changed.

Does not change anything.

Another possibility would be to delete aclocal.m4 and autom4te.cache/ before calling autoreconf -vfi. Don't know whether that helps.

Does not work either.

...

AC_ARG_ENABLE(exa, AC_HELP_STRING([--disable-exa], - [Disable EXA support [[default enabled]]]), + [Disable EXA support [[default=no]]]), [EXA="$enableval"], [EXA=yes])

This is only replaced in text strings - other configure scripts have even stranger usage patterns.

You might want to try to change this into

+ [Disable EXA support (default enabled)]),

This works.

If after reverting you still got this issue. Then the [[ quoting doesn't work as expected any more.

Matthias

It's the space inside the double-quoting that breaks autoconf, don't know why. It does not change anything to replace AC_HELP_STRING (which is deprecated) with AS_HELP_STRING. I tried to adjust the wrap-column, because it seems to be a problem with it, but that does not work also. So the solution at the moment seems to be to either use round braces or avoid the spaces. Jens -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org