(
Jump to the original submission)
Mon 20 Dec 2010 11:04:13 PM UTC, comment #12:
Fixed by eed8d21f6f01112433007ecc77a3171b89801a4f
|
Mon 20 Dec 2010 04:08:26 PM UTC, comment #11:
Can't fix a bug which is closed no ?
Setting to Important (being a regression) till we get an agreement on the meaning of "Blocker".
It'd be stupid to not have this one show up when looking for things to do before next release...
|
Mon 20 Dec 2010 02:47:56 PM UTC, comment #10:
If you change the bug severity again, you will loose write access to savannah. Leave this alone, and it will get fixed.
|
Mon 20 Dec 2010 02:44:50 PM UTC, comment #9:
Please don't be kiddish.
It has nothing to do with buildbot.
Before 06907b931859501ae1daf193d1c1576aecda1124 HAVE_LTDL was not used in the code...
|
Mon 20 Dec 2010 02:35:38 PM UTC, comment #8:
Don't ever change the severity on a bug report after I've changed it. This is not a blocker. The patch works fine by hand, it's obviously buildbot is doing something else that breaks this.
|
Mon 20 Dec 2010 02:32:09 PM UTC, comment #7:
It's blocker (both release-blocker and regression).
Note there are two slave faling (both lenny based)
|
Mon 20 Dec 2010 02:28:30 PM UTC, comment #6:
I've been fixing many other issues since then. If you hadn't started reverting all my revno.h commits, I'd have fixed this yet again too. As the patch is, it did fix OpenBSD too...Note that it worked fine in all my testing, it's just when run under buildbot there is a problem.
|
Mon 20 Dec 2010 02:23:44 PM UTC, comment #5:
Rob, the problem is still there, 13 days after you introduced it.
How long "reasonable time" is ? (reguarding http://wiki.gnashdev.org/CommitRules)
|
Sat 11 Dec 2010 11:10:42 PM UTC, comment #4:
Uhm.. looks like it isn't actually
http://gnashdev.org:8010/builders/lenny-linux-x86/builds/31/steps/make_anal/logs/stdio
|
Sat 11 Dec 2010 11:09:24 PM UTC, comment #3:
Rob, did you mention this was fixed ?
|
Tue 07 Dec 2010 04:29:07 PM UTC, comment #2:
We should be ignoring all system installation of libltdl, as we include libltdl 2.x in the source tarball. We should only be using the internal copy of libltdl, and HAVE_LTDL should be reliable. Maybe we shoudn't look for the libtool version in configure, since we know we only want 2.x.
|
Tue 07 Dec 2010 04:12:42 PM UTC, comment #1:
For the record, the problem arises on systems with libtool 1:
checking For the version of libtool... 1.x
|
Tue 07 Dec 2010 03:49:39 PM UTC, original submission:
Commit 06907b931859501ae1daf193d1c1576aecda1124 introduced use of HAVE_LTDL to switch whether or not ltdl library was built but that's not correct as there are systems on which the macro isn't defined but still ltdl library is being used (either the internal or external ones).
Example is http://gnashdev.org:8010/builders/lenny-linux-x86/builds/23/
Check configuration step, when extensions are requested.
The resulting gnashconfig.h has no HAVE_LTDL define.
Check test step, extensions loading fails (the FileIO tests)
BTW, does it make sense to disable ltdl implicitly like that ?
It'll strike back if someone builds gnash extensions outside of the gnash tree...
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 13 latest changes.