| Summary: | Upstreaming DragonFlyBSD changes from DeltaPorts | ||
|---|---|---|---|
| Product: | SDL | Reporter: | David Carlier <devnexen> |
| Component: | *don't know* | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | sezeroz |
| Version: | HG 2.1 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: |
patch
DragonFly patch #1 DragonFly patch #2 - LIBICONV_PLUG |
||
Created attachment 4592 [details]
DragonFly patch #1
Created attachment 4593 [details]
DragonFly patch #2 - LIBICONV_PLUG
The original patch was broken: it pushed generated SDL_config.h and SDL_revision.h. I fixed it and split it into two parts. The first one _should_ be OK, but asking Sam because we are close to making a release. The second part which defines LIBICONV_PLUG in SDL_iconv.c, I'm not sure about. Does DragonFly ship with libiconv, build it with LIBICONV_PLUG in CFLAGS or CPPFLAGS, but _not_ define LIBICONV_PLUG in iconv.h? Should we conditionalize defining LIBICONV_PLUG only to DragonFly? And if we do, why not handle it in configure.ac?? (In reply to Ozkan Sezer from comment #3) > The second part which defines LIBICONV_PLUG in SDL_iconv.c, I'm not > sure about. Does DragonFly ship with libiconv, build it with > LIBICONV_PLUG in CFLAGS or CPPFLAGS, but _not_ define LIBICONV_PLUG > in iconv.h? Should we conditionalize defining LIBICONV_PLUG only > to DragonFly? And if we do, why not handle it in configure.ac?? Looked at https://gitweb.dragonflybsd.org/dragonfly.git iconv.h is not from libiconv, nor is the iconv.c source. How is LIBICONV_PLUG relevant here? I understand if the second part is refused and indeed since the release is closed. It is also indeed not iconv from the system but from port which is useful when building some softwares (e.g. PHP) the LIBICONV_PLUG constant avoid the iconv calls to be prefixed with "lib". But again not essential patch just nice to have but not hard feelings if not. (In reply to David Carlier from comment #5) > I understand if the second part is refused and indeed since the release is > closed. It is also indeed not iconv from the system but from port which is > useful when building some softwares (e.g. PHP) the LIBICONV_PLUG constant > avoid the iconv calls to be prefixed with "lib". But again not essential > patch just nice to have but not hard feelings if not. OK then. - Patch #2: My vote is rejecting it. Not sure what breakage it would cause with any other setups. - Patch #1: Looks like fixes. Sam: Apply now, or wait until after release? The patch #1 is applied for release, thanks! https://hg.libsdl.org/SDL/rev/cc49d5b671f9 |
Created attachment 4591 [details] patch And fixing iconv linkage failure.