devel/mingw: fix for -fno-common build or...?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

devel/mingw: fix for -fno-common build or...?

Christian Weisgerber
Even more so than the micro-controller toolchains that I already
touched, this port feels massively outdated and should probably be
replaced by some newer version.  That, however, is a substantial
undertaking and needs to be done by somebody who can verify that
the result actually works.

So here are the fixes required to build this with -fno-common,
straight from the GNU binutils history.  (So easy to find with
tog after cloning a local copy of the Git repo... I digress.)

Do we want this?  Should the port be deleted instead?


Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/mingw/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile 14 May 2020 15:30:46 -0000 1.22
+++ Makefile 16 Feb 2021 23:09:56 -0000
@@ -3,14 +3,12 @@
 COMMENT = development environment for native Windows applications
 
 V = 1.0.1
-REVISION = 9
+REVISION = 10
 BASENAME = x86-mingw32-build
 DISTNAME = ${BASENAME}-${V}-sh
 PKGNAME = mingw-${V}
 WRKDIST = ${WRKDIR}/${BASENAME}-${V}
 CATEGORIES = devel
-
-HOMEPAGE = http://www.mingw.org/
 
 MAINTAINER = Paul Irofti <[hidden email]>
 
Index: patches/patch_binutils-2.20.1-binutils_dwarf_h
===================================================================
RCS file: patches/patch_binutils-2.20.1-binutils_dwarf_h
diff -N patches/patch_binutils-2.20.1-binutils_dwarf_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch_binutils-2.20.1-binutils_dwarf_h 16 Feb 2021 23:09:56 -0000
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/binutils/dwarf.h.orig
++++ binutils-2.20.1/binutils/dwarf.h
+@@ -111,6 +111,7 @@ extern int do_debug_frames_interp;
+ extern int do_debug_macinfo;
+ extern int do_debug_str;
+ extern int do_debug_loc;
++extern int do_wide;
+
+ extern void init_dwarf_regnames (unsigned int);
+
Index: patches/patch_binutils-2.20.1-binutils_readelf_c
===================================================================
RCS file: patches/patch_binutils-2.20.1-binutils_readelf_c
diff -N patches/patch_binutils-2.20.1-binutils_readelf_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch_binutils-2.20.1-binutils_readelf_c 16 Feb 2021 23:09:56 -0000
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/binutils/readelf.c.orig
++++ binutils-2.20.1/binutils/readelf.c
+@@ -149,7 +149,6 @@
+ #include "filenames.h"
+
+ char * program_name = "readelf";
+-int do_wide;
+ static long archive_file_offset;
+ static unsigned long archive_file_size;
+ static unsigned long dynamic_addr;
Index: patches/patch_binutils-2.20.1-gprof_hist_c
===================================================================
RCS file: patches/patch_binutils-2.20.1-gprof_hist_c
diff -N patches/patch_binutils-2.20.1-gprof_hist_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch_binutils-2.20.1-gprof_hist_c 16 Feb 2021 23:09:56 -0000
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/gprof/hist.c.orig
++++ binutils-2.20.1/gprof/hist.c
+@@ -48,6 +48,8 @@
+ static histogram *find_histogram (bfd_vma lowpc, bfd_vma highpc);
+ static histogram *find_histogram_for_pc (bfd_vma pc);
+
++histogram * histograms;
++unsigned num_histograms;
+ double hist_scale;
+ static char hist_dimension[16] = "seconds";
+ static char hist_dimension_abbrev = 's';
Index: patches/patch_binutils-2.20.1-gprof_hist_h
===================================================================
RCS file: patches/patch_binutils-2.20.1-gprof_hist_h
diff -N patches/patch_binutils-2.20.1-gprof_hist_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch_binutils-2.20.1-gprof_hist_h 16 Feb 2021 23:09:56 -0000
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/gprof/hist.h.orig
++++ binutils-2.20.1/gprof/hist.h
+@@ -30,8 +30,8 @@
+   int *sample;           /* Histogram samples (shorts in the file!).  */
+ } histogram;
+
+-histogram *histograms;
+-unsigned num_histograms;
++extern histogram *histograms;
++extern unsigned num_histograms;
+
+ /* Scale factor converting samples to pc values:
+    each sample covers HIST_SCALE bytes.  */

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: devel/mingw: fix for -fno-common build or...?

George Koehler-2
On Wed, 17 Feb 2021 00:23:03 +0100
Christian Weisgerber <[hidden email]> wrote:

> Even more so than the micro-controller toolchains that I already
> touched, this port feels massively outdated and should probably be
> replaced by some newer version.  That, however, is a substantial
> undertaking and needs to be done by somebody who can verify that
> the result actually works.
>
> So here are the fixes required to build this with -fno-common,
> straight from the GNU binutils history.  (So easy to find with
> tog after cloning a local copy of the Git repo... I digress.)
>
> Do we want this?  Should the port be deleted instead?

Unless someone updates this, ok gkoehler@ to delete the port.

This port combines gcc 3.4.5 from 2005 with a mingw runtime from 2009
or 2010 to target Microsoft Windows.  I never used this port. I did
use MinGW, with a newer gcc, running on Windows itself, around 2014.
Today, I don't use mingw.

http://mingw-w64.org/doku.php is a fork of the runtime that targets
both amd64 and i386.  (The runtime provides header files and such for
linking to Windows system libraries.  You would use the runtime with
the mingw targets of GNU binutils and gcc.)

https://osdn.net/projects/mingw/ is the original MinGW, has the
runtime for only i386.  Years ago, they merged their runtime from
2 packages (mingwrt, w32api) into 1 (wsl).

If I would use MinGW today, I would not cross-compile from OpenBSD.
I would first try MSYS2 https://www.msys2.org/ on Windows itself.
MSYS2 uses mingw-w64 and provides bash with gcc (or clang).

If I would cross-compile from OpenBSD, I would first try to use lld
and clang with the mingw-w64 runtime.  If it would work, I would have
skipped compiling gcc and binutils.  I would ignore this old port with
its obsolete gcc.    --George

Reply | Threaded
Open this post in threaded view
|

Re: devel/mingw: fix for -fno-common build or...?

Klemens Nanni-2
On Wed, Feb 17, 2021 at 12:11:16AM -0500, George Koehler wrote:
> On Wed, 17 Feb 2021 00:23:03 +0100
> Christian Weisgerber <[hidden email]> wrote:
> > Do we want this?  Should the port be deleted instead?
>
> Unless someone updates this, ok gkoehler@ to delete the port.
+1

> This port combines gcc 3.4.5 from 2005 with a mingw runtime from 2009
> or 2010 to target Microsoft Windows.  I never used this port. I did
> use MinGW, with a newer gcc, running on Windows itself, around 2014.
> Today, I don't use mingw.
>
> http://mingw-w64.org/doku.php is a fork of the runtime that targets
> both amd64 and i386.  (The runtime provides header files and such for
> linking to Windows system libraries.  You would use the runtime with
> the mingw targets of GNU binutils and gcc.)
>
> https://osdn.net/projects/mingw/ is the original MinGW, has the
> runtime for only i386.  Years ago, they merged their runtime from
> 2 packages (mingwrt, w32api) into 1 (wsl).
>
> If I would use MinGW today, I would not cross-compile from OpenBSD.
> I would first try MSYS2 https://www.msys2.org/ on Windows itself.
> MSYS2 uses mingw-w64 and provides bash with gcc (or clang).
>
> If I would cross-compile from OpenBSD, I would first try to use lld
> and clang with the mingw-w64 runtime.  If it would work, I would have
> skipped compiling gcc and binutils.  I would ignore this old port with
> its obsolete gcc.    --George
This reads like a waste of time;  for users, porters and package build
infrastructure.

It is severly outdated and has no amd64 support,  I'd rather send it to
the attic.