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

Cann't compile SDL from repository [r6302] #556

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

Cann't compile SDL from repository [r6302] #556

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
abandoned Bug has been abandoned for various reasons

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: 2.0.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2012-02-26 06:33:40 +0000, O01eg wrote:

When I try to compile SDL I get next error:

libtool: compile: gcc -O2 -march=core2 -mtune=core2 -pipe -msse -msse2 -msse3 -mssse3 -mmmx -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -DUSING_GENERATED_CONFIG_H -I./include -mmmx -m3dnow -msse -msse2 -fvisibility=hidden -D_REENTRANT -DHAVE_LINUX_VERSION_H -Wall -MMD -MT build/SDL_dummy_main.o -c src/main/dummy/SDL_dummy_main.c -fPIC -DPIC -o build/.libs/SDL_dummy_main.o
ar cru build/libSDL2main.a build/SDL_dummy_main.o
ar: build/SDL_dummy_main.o: No such file or directory
make: *** [build/libSDL2main.a] Error 1
make: *** Waiting for unfinished jobs....

On 2012-02-27 06:14:39 +0000, Gabriel Jacobo wrote:

I can't reproduce this, I just tried it with a fresh checkout in Ubuntu Oneiric 64 bits.

On 2012-02-27 08:30:51 +0000, O01eg wrote:

Created attachment 829
Generated Makefile

Broken Makefile

On 2012-02-27 08:36:11 +0000, O01eg wrote:

Configure options: --disable-static --enable-assertions=paranoid --enable-sse2 --disable-esd --disable-pulseaudio --disable-nas --disable-fusionsound

In Makefile present next lines:

SDLMAIN_OBJECTS = $(objects)/SDL_dummy_main.o
...
$(objects)/SDL_dummy_main.o: ./src/main/dummy/SDL_dummy_main.c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -MMD -MT $@ -c $< -o $@

But libtool place SDL_dummy_main.o into build/.libs/

libtool version: 2.4

On 2012-02-27 08:41:18 +0000, Gabriel Jacobo wrote:

It seems the problem is --disable-static, remove that switch from the configure line and it works fine. This should be fixed anyway.

On 2012-05-26 09:29:10 +0000, Gabriel Jacobo wrote:

I'm assigning this to me, I'll try to fix it soon.

On 2013-03-21 00:31:33 +0000, Sam Lantinga wrote:

*** Bug 1541 has been marked as a duplicate of this bug. ***

On 2013-04-04 18:57:47 +0000, Gabriel Jacobo wrote:

Created attachment 1099
Fix for --disable-static bug

The attached patch should solve the problem, if anyone else can confirm or Sam gives the go ahead I'll commit it.

On 2013-04-17 14:23:37 +0000, wrote:

Created attachment 1114
Use libtool everywhere

On 2013-04-17 14:24:04 +0000, wrote:

The problem is caused by mixing libtool builds with non-libtool builds. The quick fix is to replace .o and .a with .lo and .a, replace explicit calls to ar and ranlib with $(LIBTOOL) --mode=link, and replace explicit install calls with $(LIBTOOL) --mode=install. I've attached a patch to the ticket.

On 2013-04-17 14:29:34 +0000, Gabriel Jacobo wrote:

Thanks John, but I had already attached a patch quite similar to yours :)

The thing is, we will probably remove the --disable-static switch altogether unless someone comes up with a good reason not to.

On 2013-07-08 23:55:12 +0000, Ryan C. Gordon wrote:

(In reply to comment # 10)

The thing is, we will probably remove the --disable-static switch altogether
unless someone comes up with a good reason not to.

In the meantime, it's probably worth applying this patch instead of leaving it broken.

--ryan.

On 2013-07-09 08:37:28 +0000, Gabriel Jacobo wrote:

Sam said that he remembered there was probably a reason behind doing things without libtool, that's why the patch hasn't been applied.

On 2013-07-09 10:53:22 +0000, Sam Lantinga wrote:

If we're going to take action on this bug before 2.0 ship, I'd rather remove the --disable-static option.

On 2013-08-20 20:24:23 +0000, Julian Ospald wrote:

We gentoo devs are currently working on packaging SDL2 and the brokenness of --disable-static is a major bummer for us. It is common to provide this as an option for the user, so he can control static libraries globally.

I do not see any reason to remove this feature. It will rather force us to apply patches downstream and will slow us down on version bumps.

On 2013-08-21 09:26:36 +0000, Sam Lantinga wrote:

The problem with --disable-static, at least conceptually, is that there are two libraries which are not available in dynamic versions, and we want them to always be available.

There are folks on other operating systems which have in the past complained about libtool because of bugs in their OS libtool installations. I'm not opposed to putting that back if there are compelling reasons to do so.

Thoughts?

On 2013-08-28 21:35:12 +0000, Julian Ospald wrote:

(In reply to Sam Lantinga from comment # 15)

The problem with --disable-static, at least conceptually, is that there are
two libraries which are not available in dynamic versions, and we want them
to always be available.

I am unable to follow here.
I get:
/usr/lib64/libSDL2.a
/usr/lib64/libSDL2_test.a
/usr/lib64/libSDL2main.a

and:
/usr/lib64/libSDL2.so
/usr/lib64/libSDL2_test.so
/usr/lib64/libSDL2main.so

There are folks on other operating systems which have in the past complained
about libtool because of bugs in their OS libtool installations. I'm not
opposed to putting that back if there are compelling reasons to do so.

Thoughts?

I don't have a strong opinion about libtool. I'd just like this bug resolved without loosing the ability of disabling static libs for compile time.

On 2013-12-18 09:01:54 +0000, Daniel Scharrer wrote:

Created attachment 1499
MingW fixes for "Use libtool everywhere"

The "Use libtool everywhere" patch posted john and applied in Gentoo breaks (cross-)compilation with MingW.

First, linking fails completely:

libtool: link: `build/version.lo' is not a valid libtool object

This is because version.o was renamed to .lo while the output of the resource compiler is obviously not a libtool object. Renaming it back to .o doesn't work either, as libtool will then complain about non-libtool objects. What does work however is wrapping the $(WINDRES) call with libtool.

Now linking the static library works, but libtool skips the dynamic library:

*** Warning: linker path does not have real file for library -luuid.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/i686-w64-mingw32/lib/libuuid.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

This can be fixed by changing -luuid into -Wl,-luuid to bypass libtool. A similar workaround was applied in GTK+ 3: https://bugzilla.gnome.org/show_bug.cgi?id=642214

(In reply to Julian Ospald from comment # 16)

(In reply to Sam Lantinga from comment # 15)

The problem with --disable-static, at least conceptually, is that there are
two libraries which are not available in dynamic versions, and we want them
to always be available.

I am unable to follow here.
I get:
/usr/lib64/libSDL2.a
/usr/lib64/libSDL2_test.a
/usr/lib64/libSDL2main.a

and:
/usr/lib64/libSDL2.so
/usr/lib64/libSDL2_test.so
/usr/lib64/libSDL2main.so

This won't work on all platforms as libSDL2main contains the main() entry point, at least on Windows. Also, linking the SDL2main dll will fail with undefined references to SDL functions. I got around this by adding -all-static to the SDL2main and SDL2_test link commands so that libtool does not try to link dynamic libraries. I'm no libtool/autoconf expert, but it seems to work fine (always creates static SDLmain), even with --disable-static.

On 2018-08-06 21:20:20 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned Bug has been abandoned for various reasons
Projects
None yet
Development

No branches or pull requests

1 participant