Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autoreconf failure #748

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

autoreconf failure #748

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
wontfix This will not be worked on

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.15
Reported for operating system, platform: Linux, Other

Comments on the original bug report:

On 2014-01-08 16:32:30 +0000, Vicente Olivert Riera wrote:

Created attachment 1515
error log

I was trying to apply this patch (http://hg.libsdl.org/SDL/rev/91ad7b43317a) to fix this compilation problem:
http://autobuild.buildroot.net/results/bf8/bf83466a7bbb0635d97fe279a18778d92f20bea2/build-end.log

This patch modifies configure.in, so you need to run autoreconf to make it take effect. The problem is, when you run autoreconf you will face with problems like this one:

configure.in:364: error: possibly undefined macro: AM_PATH_ALSA
configure.in:463: error: possibly undefined macro: AM_PATH_ESD

I have modified the configure.in to try to fix this problem. Here are the changes I have made:

--- sdl-1.2.15/configure.in.orig 2014-01-08 16:27:59.780363111 +0000
+++ sdl-1.2.15/configure.in 2014-01-08 16:28:34.682922738 +0000
@@ -361,7 +361,7 @@ CheckALSA()
AC_HELP_STRING([--enable-alsa], [support the ALSA audio API [[default=yes]]]),
, enable_alsa=yes)
if test x$enable_audio = xyes -a x$enable_alsa = xyes; then

  •    AM_PATH_ALSA(0.9.0, have_alsa=yes, have_alsa=no)
    
  •    AC_CHECK_HEADER(alsa/asoundlib.h, have_alsa=yes, have_alsa=no)
       # Restore all flags from before the ALSA detection runs
       CFLAGS="$alsa_save_CFLAGS"
       LDFLAGS="$alsa_save_LDFLAGS"
    

@@ -460,7 +460,7 @@ CheckESD()
AC_HELP_STRING([--enable-esd], [support the Enlightened Sound Daemon [[default=yes]]]),
, enable_esd=yes)
if test x$enable_audio = xyes -a x$enable_esd = xyes; then

  •    AM_PATH_ESD(0.2.8, have_esd=yes, have_esd=no)
    
  •    AC_CHECK_HEADER(esd.h, have_esd=yes, have_esd=no)
       if test x$have_esd = xyes; then
           AC_ARG_ENABLE(esd-shared,
    

AC_HELP_STRING([--enable-esd-shared], [dynamically load ESD audio support [[default=yes]]]),

After doing those changes, the problem with the undefined macros is solved. But unfortunately I have the problem of the attached log file, and I don't know how to fix it.

On 2014-01-08 19:19:31 +0000, Azamat H. Hackimov wrote:

You should run autogen.sh in SDL package root directory after applying patch. SDL uses bit tricky automake/autoconf configuration, so all m4 macros placed in acinclude instead traditional m4 directory.
Or, you can define new AT_M4DIR enviroment variable to make autoreconf works properly (ex. AT_M4DIR="/usr/share/aclocal acinclude")

On 2014-01-09 10:14:18 +0000, Vicente Olivert Riera wrote:

(In reply to Azamat H. Hackimov from comment # 1)

Or, you can define new AT_M4DIR enviroment variable to make autoreconf works
properly (ex. AT_M4DIR="/usr/share/aclocal acinclude")

Please, could you expand this reply? I'm not an autotools expert, but that option seems to be the most elegant.

On 2014-01-09 13:18:47 +0000, Vicente Olivert Riera wrote:

(In reply to Azamat H. Hackimov from comment # 1)

Or, you can define new AT_M4DIR enviroment variable to make autoreconf works
properly (ex. AT_M4DIR="/usr/share/aclocal acinclude")

Also, if you know that works, why don't you do that in order to be more "standard" and not having a tricky automake/autoconf configuration?

On 2014-01-09 15:59:53 +0000, Azamat H. Hackimov wrote:

My command is wrong, sorry about that (it can applied in my distribution). Proper way is run

aclocal -I acinclude
autoconf

or with script from SDL:

./autogen.sh

I'm not SDL developer, so I can't to say why that happen.

On 2014-01-09 16:07:02 +0000, Vicente Olivert Riera wrote:

I can get it working with calling autogen.sh, but it would be great if some SDL developer gives a valid solution which works with autoreconf, so..., let's wait and hope that a SDL developer reads this bug report.

On 2015-08-25 09:38:21 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we will accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.

@SDLBugzilla SDLBugzilla added bug endoflife Bug might be valid, but SDL-1.2 is EOL. labels Feb 10, 2021
@sezero sezero added wontfix This will not be worked on and removed endoflife Bug might be valid, but SDL-1.2 is EOL. labels Mar 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants