We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5406 - Upstreaming DragonFlyBSD changes from DeltaPorts
Summary: Upstreaming DragonFlyBSD changes from DeltaPorts
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.1
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-20 12:20 UTC by David Carlier
Modified: 2020-12-20 20:09 UTC (History)
1 user (show)

See Also:

Attachments
patch (25.61 KB, patch)
2020-12-20 12:20 UTC, David Carlier 		Details | Diff
DragonFly patch #1 (8.99 KB, patch)
2020-12-20 13:43 UTC, Ozkan Sezer 		Details | Diff
DragonFly patch #2 - LIBICONV_PLUG (325 bytes, patch)
2020-12-20 13:44 UTC, Ozkan Sezer 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Carlier 2020-12-20 12:20:36 UTC 
Created attachment 4591 [details]
patch

And fixing iconv linkage failure.
Comment 1 Ozkan Sezer 2020-12-20 13:43:58 UTC 
Created attachment 4592 [details]
DragonFly patch #1
Comment 2 Ozkan Sezer 2020-12-20 13:44:37 UTC 
Created attachment 4593 [details]
DragonFly patch #2 - LIBICONV_PLUG
Comment 3 Ozkan Sezer 2020-12-20 13:51:21 UTC 
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??
Comment 4 Ozkan Sezer 2020-12-20 14:16:54 UTC 
(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?
Comment 5 David Carlier 2020-12-20 15:15:27 UTC 
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.
Comment 6 Ozkan Sezer 2020-12-20 16:57:18 UTC 
(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?
Comment 7 Sam Lantinga 2020-12-20 20:09:57 UTC 
The patch #1 is applied for release, thanks!
https://hg.libsdl.org/SDL/rev/cc49d5b671f9