Re: Preferred way of repocopy in terms of git

[Tijl Coosemans]

On Mon, 10 May 2021 09:30:56 +0200 Mathieu Arnold 
wrote:
> On Fri, May 07, 2021 at 11:32:48PM +0600, Muhammad Moinur Rahman wrote:
>> What is the preferred way of doing ports repocopy in git? In the hard
>> way I can see moving it into two locations and merging them. But is
>> there any easier way of doing it?
> 
> Well, here is what I did when I added lang/perl5.34:
> 
> cp -R lang/perl5-devel lang/perl5.34
> # change stuff
> git add lang/perl5.34
> git commit
> 
> I don't really see any other way to do this, Git has absolutely no clue
> about copies or moves.

It might still be useful to do the copy and changes as two separate
commits.  Even if git doesn't do anything with that, our next vcs might
and reconstructing copy history is faster and less error prone with
unmodified copies.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: /usr/ports/print/ghostscript9-agpl-base gs_ll3.ps: Error: /undefinedresource (fwd)

[Tijl Coosemans]

On Tue, 04 May 2021 22:01:46 +0200 "Julian H. Stacey" 
wrote:
>> Delete all those .pkgsave files.  These are backups created by pkg when
>> it has to install a file over an existing file.  It means a previous
>> version of ghostscript wasn't deleted properly.  
> 
> Thanks Coosemans, I ran my compare+delete
> http://berklix.com/~jhs/src/bsd/jhs/bin/public/cmpd/cmpd.c
> cmpd -d -v \
>  /usr/local/share/ghostscript/fonts/Fontmap.pkgsave \
>  /usr/local/share/ghostscript/fonts/Fontmap
> cmpd -d -v \
>  /usr/local/share/ghostscript/9.52/Resource/Init/Fontmap.pkgsave \
>  /usr/local/share/ghostscript/9.52/Resource/Init/Fontmap
> cmpd -d -v \
>  /usr/local/share/ghostscript/9.52/Resource/Init/Fontmap.GS.pkgsave \
>  /usr/local/share/ghostscript/9.52/Resource/Init/Fontmap.GS
> All identical & deleted.
> 
> & rebooted but no better, gs still fails.

In your original message there were more than these 3.  Did you delete
all of them?  Try "find /usr/local/share/ghostscript -name '*.pkgsave'".
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: /usr/ports/print/ghostscript9-agpl-base gs_ll3.ps: Error: /undefinedresource (fwd)

[Tijl Coosemans]

On Tue, 04 May 2021 16:29:47 +0200 "Julian H. Stacey" 
wrote:
> Hi ports@ people,
> I wrote this to doc...@freebsd.org Sun, 02 May 2021 23:43:44 +0200
> but no reply by Tue May  4 16:26:48 CEST 2021.
> Have others seen similar or got ideas to fix gs ghostscript ?
> ---
> 
> Hi doc...@freebsd.org
> as MAINTAINER= in /usr/ports/print/ghostscript9-agpl-base
> 
> I'm stuck, gs fails to start, suggestions please ?
> 
> FreeBSD lapr.js.berklix.net 12.2-STABLE FreeBSD 12.2-STABLE #1038: Mon Feb 15 
> 02:04:28 CET 2021 
> j...@lapr.no.berklix.net:/data/release/s2/usr/src/sys/amd64/compile/LAPR.small
>   amd64
> 
> % printenv
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin
> TERM=xterm
> DESTDIR=/
> TERMPATH=/etc/termcap:/usr/share/misc/termcap
> NOCLEANDEPENDS=
> % printenv
> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin
> TERM=xterm
> DESTDIR=/
> TERMPATH=/etc/termcap:/usr/share/misc/termcap
> NOCLEANDEPENDS=
> 
> % which gs
> /usr/local/bin/gs
> % ls -l /usr/local/bin/gs
> - -rwxr-xr-x  1 root  wheel  7648 Apr 29 11:02 /usr/local/bin/gs*
> 
> gs
> GPL Ghostscript 9.52 (2020-03-19)
> Copyright (C) 2020 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> see the file COPYING for details.
> While reading gs_ll3.ps:
> Error: /undefinedresource in findresource
> Operand stack:
>
> (gs_icc.ps\000gs_mex_e.ps\000gs_mro_e.ps\000gs_pdf_e.ps\000gs_wan_e.ps\000pdf_ops.ps\000pdf_rbld.ps\000pdf_base.ps\000pdf_draw.ps\000gs_cff.ps\000gs_mgl_e.ps\000gs_ttf.ps\000pdf_font.ps\000pdf_main.ps\000pdf_sec.ps\000gs_epsf.ps\000gs_pdfwr.ps)
>(gs_ll3.ps)   1   Pscript5Idiom.pkgsave   IdiomSet   6   
> Pscript5Idiom.pkgsave
> Execution stack:
>%interp_exit   --nostringval--   findresource   %loop_continue   
> findresource   findresource   findresource   false   1   %stopped_push   
> --nostringval--   1902   7   5   %oparray_pop   findresource   findresource   
> --dict:16/18(ro)(G)--   --dict:2/2(G)--   findresource   2   %dict_continue   
> findresource   findresource   1900   5   5   %oparray_pop   findresource   
> %errorexec_pop   findresource   findresource   findresource   findresource
> Dictionary stack:
>--dict:943/1123(G)--   --dict:0/20(G)--   --dict:77/200(L)--   
> --dict:943/1123(G)--   --dict:38/43(G)--   --dict:16/18(ro)(G)--
> Current allocation mode is global
> Current file position is 18941
> 
> Any ideas please ?
> I rebuilt my machine with make worl & generic then custom kernel &
> a load of downloaded pkg 
> pkg info -a | wc -l
> 1348
> 
> ive since run 
> cd /usr/ports/print/ghostscript9-agpl-base 
> make clean
> make reinstall
> 
> gs -help
> ends
>/usr/local/share/ghostscript/9.52/Resource/Init :
>/usr/local/share/ghostscript/9.52/lib :
>/usr/local/share/ghostscript/9.52/Resource/Font :
>/usr/local/share/ghostscript/fonts : /usr/local/share/fonts
>Ghostscript is also using fontconfig to search for font files
> 
> my /usr/local/share/ghostscript/9.52/Resource/ has no Init should it ?
> drwxr-xr-x   2 root  bin  4608 May  2 22:33 ./
> drwxr-xr-x  11 root  bin   512 May  2 22:33 ../
> - -rw-r--r--   1 root  wheel3297 May  2 22:23 FAPIcidfmap
> - -rw-r--r--   1 root  wheel3297 Jun 16  2020 FAPIcidfmap.pkgsave
> - -rw-r--r--   1 root  wheel1158 May  2 22:23 FAPIconfig
> - -rw-r--r--   1 root  wheel1158 Jun 16  2020 FAPIconfig.pkgsave
> - -rw-r--r--   1 root  wheel1468 May  2 22:23 FAPIfontmap
> - -rw-r--r--   1 root  wheel1468 Jun 16  2020 FAPIfontmap.pkgsave
> - -rw-r--r--   1 root  wheel2857 May  2 22:23 FCOfontmap-PCLPS2
> - -rw-r--r--   1 root  wheel2857 Jun 16  2020 FCOfontmap-PCLPS2.pkgsave
> - -rw-r--r--   1 root  wheel 109 May  2 22:23 Fontmap
> - -rw-r--r--   1 root  wheel   12929 May  2 22:23 Fontmap.GS
> - -rw-r--r--   1 root  wheel   12929 Jun 16  2020 Fontmap.GS.pkgsave
> - -rw-r--r--   1 root  wheel 109 Jun 16  2020 Fontmap.pkgsave
> - -rw-r--r--   1 root  wheel4183 May  2 22:23 cidfmap
> - -rw-r--r--   1 root  wheel4183 Jun 16  2020 cidfmap.pkgsave
> - -rw-r--r--   1 root  wheel  218021 May  2 22:23 gs_agl.ps
> 
> /usr/local/share/ghostscript/fonts
> - -rw-r--r--  1 root  wheel   13643 Sep 19  2020 Fontmap
> - -rw-r--r--  1 root  wheel   13643 Jul  6  2019 Fontmap.pkgsave
> lrwxr-xr-x  1 root  wheel  49 Sep 19  2020 GothicBBB-Medium@ -> 
> /usr/local/share/fonts/std.ja_JP/GothicBBB-Medium
> lrwxr-xr-x  1 root  wheel  53 Sep 19  2020 GothicBBB-Medium.gs7@ -> 
> /usr/local/share/fonts/std.ja_JP/GothicBBB-Medium.gs7
> lrwxr-xr-x  1 root  wheel  44 Sep 19  2020 MSung-Light@ -> 
> /usr/local/share/fonts/std.zh_CN/MSung-Light
> lrwxr-xr-x  1 root  wheel  45 Sep 19  2020 Ryumin-Light@ -> 
> /usr/local/share/fonts/std.ja_JP/Ryumin-Light
> lrwxr-xr-x  1 root  wheel  49 Sep 19  2020 Ryumin-Light.gs7@ -> 
> /usr/local/share/fonts/std.ja_JP/Ryumin-Light.gs7
> lrwxr-xr-x  1 root  wheel 

Re: Call for testing: LibreOffice 7.1.1 release

[Tijl Coosemans]

On Mon, 8 Mar 2021 21:13:25 +1000 Dima Panov  wrote:
> gt3 vcl is not fully complete yet ans we (team) prefer to keep qt5 as default

What is missing then?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Call for testing: LibreOffice 7.1.1 release

[Tijl Coosemans]

On Fri, 5 Mar 2021 01:16:40 +1000 Dima Panov  wrote:
> Hello!
> 
> LibreOffice 7.1.1 release is out and office@FreeBSD team calls everyone 
> interested to join us in testing cycle
> 
> Our WIP repository available at GitHub, 
> https://github.com/freebsd/freebsd-ports-libreoffice.
> Of course, we support ports’ OVERLAY feature by adding:
> 
> OVERLAYS+=/path/to/freebsd-ports-libreoffice
> 
> to /etc/make.conf
> 
> Poudriere users should follows next steps:
> 
> sudo poudriere ports -c -F -p portoverlay
> cd ${LOCALBASE}/poudriere/ports/portsoverlay
> git clone https://github.com/lwhsu/freebsd-ports-libreoffice .
> git checkout master
> poudriere bulk -j 122amd64 -p portstree -O portsoverlay editors/libreoffice
> 
> You can start the LibreOffice with x11 UI backend by setting
> environment variable:
> 
> SAL_USE_VCLPLUGIN=gen
> 
> where ‘gen’ can be replaced by x11, gtk3, qt5, kf5, depends on selected build 
> options to get a required vcl active
> 
> Qt5 vcl is already locked to use cairo font renderer.
> 
> Patches and suggestions are welcome!

With the 7.1.0 version I'm using the gtk3 backend again and haven't
noticed any problems yet.  If others can confirm that, maybe it can be
made the default again when you commit 7.1.1?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How should follks migrate from linux_base-c6 to linux_base-c7?

[Tijl Coosemans]

On Tue, 31 Dec 2019 05:28:39 -0800 David Wolfskill
 wrote:
> As noted in
> ,
> the -c6 ports "expire tomorrow."
> 
> I don't see a documented process for migrating from linux_base-c6 to
> linux_base-c7; perhaps I'm being thicker than usual.
> 
> For example, from prior migrations (e.g., the 20141209 entry in
> ports/UPDATING), there's a mention of:
> 
> |  2. Persistently update the Linux kernel version in /etc/sysctl.conf:
> |
> | compat.linux.osrelease=2.6.18

This was needed when the default value was 2.4., but nowadays
the default is already higher than 2.6.18 so you can just remove this.
Besides that it's just a matter of removing c6 packages and installing c7
packages.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: dos2unix patch?

[Tijl Coosemans]

On Thu, 12 Sep 2019 14:23:58 +0900 Koichiro Iwao 
wrote:
> is it possible to run dos2unix to patches fetched from PATCH_SITES?
> or how can I change order of patch and dos2unix.
> 
> I would like to apply dos2unix-ed patches to dos2unix-ed source.
> Alternatively, applying patch first and then running dos2unix on
> patched-source is OK to me.
> 
> Patches fetched from PATCH_SITES have .patch suffix so I added *.patch
> to DOS2UNIX_GLOB but it didn't work.
> 
> USES= dos2unix
> DOS2UNIX_GLOB= *.c *.h

You could add the patches to DISTFILES instead of PATCHFILES and then
maybe do-extract will just copy them to WRKDIR, but if not, you can set
EXTRACT_ONLY to the original distfile and copy the patches to WRKDIR in
post-extract.  Then dos2unix should work and you can add the WRKDIR
patches to EXTRA_PATCHES.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

[Tijl Coosemans]

On Sun, 7 Apr 2019 23:57:12 -0700 Mark Millard via freebsd-ports
 wrote:
> On 2019-Apr-7, at 22:16, Gerald Pfeifer  wrote:
>> Hmm, I received zero feedback on this proposal, when it appeared
>> important for a number of users.
>> 
>> What's your take, Andreas, Tijl (your patch essentially with a bit
>> of an updated description), and toolchain?
>> 
>> Gerald
>> 
>> On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
>>> Hi Tijl, hi everyone,
>>> 
>>> and let me add Andreas who has been helping on the GCC side (both
>>> ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
>>>
>>> On Sun, 24 Feb 2019, Tijl Coosemans wrote:
>>>> GCC_4.3.0 instead of GCC_3.3.0.  The gcc commit that changed this
>>>> doesn't explain why this was done, but we'll have to make the same
>>>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
>>>> part of the ABI).  This isn't a blocker for the patch.
>>>> 
>>>> I emailed the patch to gerald on 2017-02-21.  He responded in the usual
>>>> way that he prefers patches submitted upstream and because I thought the
>>>> patch would not be accepted upstream he proposed an alternative solution
>>>> where gcc would always add -rpath on FreeBSD so you didn't have to
>>>> specify it on the command line.  I responded this wouldn't fix the case
>>>> where clang was used as a linker (e.g. to combine fortran and c++ code
>>>> in one program) and that the FAQ on the gcc website said it was a bad
>>>> idea for other reasons.  I also said upstream might accept my patch if
>>>> it was a configure option but that the gcc configure scripts are
>>>> complicated and I didn't know where to add it exactly.  Then silence.
>>> 
>>> To move this forward, let me include an updated version of the patch
>>> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for
>>> consideration for our ports collection, initially for lang/gcc8 given
>>> that this is the default in the ports collection.
>>> 
>>> 
>>> (The lang/gcc* ports actually do carry local patches, e.g. for arm or
>>> powerpc or -fuse-ld=lld, but you are right that I usually try to get
>>> things upstream first, fixing things upstream myself when I can, or
>>> asking for help. The problem in this specific case was/is that I'm
>>> quite not enough into this area so cannot really assess and clearly
>>> stalling over that was not good.)
>>> 
>>> 
>>> Find patch-gfortran-libgcc attached which should simply plug into
>>> lang/gcc8/files and lang/gcc8-devel/files.
>>> 
>>> Feedback very welcome!
> 
> I'm not sure the following will be considered important
> for the above, but I'll note it in case.

I don't think it is relevant.  The patch only affects gfortran, not any
C/C++ compiler, and it only affects programs that currently don't run
because system libgcc_s is loaded as a dependency of some library while
another library later in the dependency chain needs gcc libgcc_s.  The
patch fixes this case by eliminating the need for gcc libgcc_s.  It does
not change which libgcc_s is loaded so any problem in the system
libgcc_s affects the same programs before and after the patch.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

[Tijl Coosemans]

On Mon, 8 Apr 2019 13:16:15 +0800 (WITA) Gerald Pfeifer
 wrote:
> This patch make 3 the default for gfortran.

s/make/makes/ but otherwise the patch looks fine.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: loose dependency

[Tijl Coosemans]

On Thu, 14 Mar 2019 11:20:09 -0600 Adam Weinberger 
wrote:
> On Thu, Mar 14, 2019 at 10:41 AM Koichiro Iwao  wrote:
>> On Thu, Mar 14, 2019 at 02:33:30PM +0100, Tijl Coosemans wrote:  
>>> Like hrs already said: since this is a build dependency you can just
>>> write:
>>>
>>> BUILD_DEPENDS=convert:graphics/ImageMagick6
>>>
>>> This does not install ImageMagick6 if 7 is installed.  It will only
>>> install 6 if convert does not exist.  It is a loose dependency.  
>>
>> I understand now. This is what I wanted. Perfect!
>>  
>>> This is not the case for RUN_DEPENDS because dependencies in a package
>>> are currently specified using package names (including version).  They
>>> would have to be specified using features where multiple packages can
>>> then provide a feature.  
>>
>> That's good to know. I'd been thinking the only difference between RUN_
>> and BUILD_DEPENDS is when the dependency is checked.  
> 
> This makes building from ports behave differently from pkg. Please,
> just make an OPTIONS_SINGLE for it, and default it to the current
> version (7), not the old version.

You mean building from ports versus poudriere?  Poudriere would always
select ImageMagick6 with the BUILD_DEPENDS line above, but that's fine.

Options aren't a good interface for this because the user can select an
option that conflicts with the installed version.  It's not really a
port option but a system-wide option.  If this needs to be configurable
for poudriere then an entry should be added to bsd.default-versions.mk.
Then the BUILD_DEPENDS line above can become:

BUILD_DEPENDS=  convert:graphics/ImageMagick${IMAGEMAGICK_DEFAULT}
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: loose dependency

[Tijl Coosemans]

On Thu, 14 Mar 2019 19:09:40 +0900 Koichiro Iwao 
wrote:
> On Thu, Mar 14, 2019 at 04:50:18PM +0900, Hiroki Sato wrote:
>> That is a workaround while increasing maintenance cost.  It is at the
>> maintainer's discretion.
> 
> Thanks for the advice. Fortunely, icons are not updated too open. The
> maintenance cost is not negligible but might be acceptable.

Like hrs already said: since this is a build dependency you can just
write:

BUILD_DEPENDS=  convert:graphics/ImageMagick6

This does not install ImageMagick6 if 7 is installed.  It will only
install 6 if convert does not exist.  It is a loose dependency.

This is not the case for RUN_DEPENDS because dependencies in a package
are currently specified using package names (including version).  They
would have to be specified using features where multiple packages can
then provide a feature.

port1:
PROVIDES=   feature1 feature2

port2:
PROVIDES=   feature2

port3:
RUN_DEPENDS=feature2:category/port1

Then pkg could see if any installed packages provide feature2 and only
install port1 by default.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Building qt5-gui port?

[Tijl Coosemans]

On Tue, 12 Mar 2019 14:01:18 -0300 Lucas Nali de Magalhães
 wrote:
>> On Feb 11, 2019, at 2:05 PM, Steve Kargl  
>> wrote:
>>> On Mon, Feb 11, 2019 at 10:08:08AM +0100, Tijl Coosemans wrote:
>>> On Sun, 10 Feb 2019 15:18:20 -0800 Steve Kargl
>>>  wrote:
>>>> On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
>>>>> 
>>>>> /usr/ports/Mk/Uses/qt-dist.mk has:
>>>>> 
>>>>> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
>>>>> CONFIGURE_ARGS+=-no-sse2
>>>>> .endif
>>>> 
>>>> Hmmm.  Oh well.  I set CPUTYPE=core2 in /etc/make.conf.
>>>> During configure of qt5-gui, it does try to use sse2,
>>>> sse3, ssse3, and even the unsupported avx.  The build
>>>> still dies.
>>> 
>>> You probably need to build all of Qt with the same flags, starting
>>> with qt5-qmake and then the other dependencies of qt5-gui.
>> 
>> Yes, that is what I decided to do.  Unfortnately, I decided
>> to use CPUTYPE=core2 to update kernel and world.  It seems a
>> recent change in FreeBSD-current has broken the drm-legacy-kmod
>> port, so no Xorg on the laptop, so no need for qt5 ports. :-)
> 
> I'm using the dirty hack
> 
> --- Makefile(revision 495009)
> +++ Makefile(working copy)
> @@ -36,6 +36,8 @@
>  # are using the obsolete 'register' key word.
>  CONFIGURE_ARGS+=   -c++std c++14
>  
> +CPUTYPE=i686
> +
>  USE_LDCONFIG=  ${PREFIX}/${QT_LIBDIR_REL}
>  
>  BUILD_WRKSRC=  ${WRKSRC}/src/${PORTNAME}
> 
> to compile and install the port. My patch isn't portable, I know. I saw
> an update to it and tried the new version: same error. I'm using
> CPUTYPE=native everywhere else, last FreeBSD 12.0-RELEASE-p3. The cpu
> is a Celeron M (Yonah). Let me know if you need more info.

native is not a valid value for CPUTYPE.  It is used in
/usr/share/mk/bsd.cpu.mk to determine cpu features, not just to set
-march= flag.  You can set CPUTYPE=yonah.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce  wrote:
> On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote:
>> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl
>>  wrote:
>>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote:
>>>> On Fri, 22 Feb 2019, Tijl Coosemans wrote:
>>>>> If I were the lang/gcc maintainer this -rpath problem would be my
>>>>> number one priority.  The current maintainer has never proposed
>>>>> any solutions and when I submit patches he always resists.  I'm
>>>>> done wasting my time fighting him.
>>>>
>>>> I'm late to this discussion (not being a Fortran/Python user) but
>>>> is there any way to remove a recalcitrant maintainer?
>>>
>>> Can you explain what you mean?  The maintainer of the lang/gcc
>>> ports is a long-time member of the GCC steering committee
>>> and a long-time maintainer of all gcc FreeBSD ports.  There
>>> are very few FreeBSD users (like 3 of us) who have commit access
>>> to the gcc tree.  Seems like a dubious idea to remove one of
>>> those 3.
>> 
>> Given the amount of time unsuspecting and half-suspecting users wasted
>> on making Fortran code (often in form of a Python extension) working
>> on FreeBSD (e.g. I probably wasted weeks), time is high to do
>> something, e.g. commit the said patches---there is an agreement that
>> they are correct, right?
> 
> Dima, gerald has always been very helpful in all my communications
> with him. Have you filed a PR for the fix? dropped  him an email?
> 
> I know we (gerald and ?? can't remember) tried a static lib change
> a few years ago. I believe it didn't work at the time due to missing
> symbols which we have since added.

This cannot be entirely correct.  I don't see what missing symbols this
would have been.  I attached my patch to bug 208120 on 2017-02-09 and
you responded it was the best idea.  mmel then discovered it didn't
entirely fix the problem on ARM where _Unwind_Backtrace has version
GCC_4.3.0 instead of GCC_3.3.0.  The gcc commit that changed this
doesn't explain why this was done, but we'll have to make the same
change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
part of the ABI).  This isn't a blocker for the patch.

I emailed the patch to gerald on 2017-02-21.  He responded in the usual
way that he prefers patches submitted upstream and because I thought the
patch would not be accepted upstream he proposed an alternative solution
where gcc would always add -rpath on FreeBSD so you didn't have to
specify it on the command line.  I responded this wouldn't fix the case
where clang was used as a linker (e.g. to combine fortran and c++ code
in one program) and that the FAQ on the gcc website said it was a bad
idea for other reasons.  I also said upstream might accept my patch if
it was a configure option but that the gcc configure scripts are
complicated and I didn't know where to add it exactly.  Then silence.
This is typical for all my conversations with him over the years so I
stopped caring.

I'm not asking that he stops maintaining gcc.  All I want is a little
more pragmatism.  User experience is more important than the patch being
in the perfect shape to be submitted upstream.  Be more practical
instead of idealistic.  The -rpath problem affects all users.
Maintaining a patch in the ports tree affects just the maintainer.  Make
decisions based on weighing pros and cons.  Ideals are just guidelines.
If a situation is bad enough then committing an imperfect patch is
better than doing nothing.

I'm a user of gcc on FreeBSD.  I'm not a gcc developer and I don't want
to become one.  If a maintainer wants patches to be in a perfect shape
he's asking users to be developers.  This doesn't work.  Either the
maintainer has to improve the patch himself or he has to play the role
of liaison between the user and an upstream developer.  If this takes
too long and the situation is bad enough then he has to be willing to
add the imperfect patch to the port.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Fri, 22 Feb 2019 19:14:33 +0200 Konstantin Belousov
 wrote:
> On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
>> 1) GCC can add new symbols or new versions of them with every release
>> which means the problem can reappear with every new GCC release and GCC
>> releases aren't aligned with FreeBSD releases.  
> Right, this is known and accepted ABI changes.  We must cope with them
> if we intend to run newer gcc and newer gcc' compiled binaries.
> 
>> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
>> runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
>> these symbols so why should we implement these third party compiler
>> runtime helper functions?  
> Because we strive to provide a usable system, not locked to one compiler.
> IMO we must support both gcc and clang and their compilation results,
> each with some version variance, regardless of the compiler used for
> the base system.
> 
>> 3) With my gfortran patch you don't need to implement anything.  It's an
>> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD.  
> Because all missed symbols are resolved from the compiler's libgcc.a before
> linker insert a reference to libgcc_s.so.1, or due to some other cause ?

Yes, for clang/clang++/gcc if you compile with -### you'll see this:
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
=> only code that uses stack unwinding uses libgcc_s

For gfortran/g++ you'll see this:
-lgcc_s -lgcc
=> almost all code uses libgcc_s

gcc/g++/gfortran also accept -shared-libgcc and -static-libgcc command
line arguments but nobody uses these.  clang/clang++ does not seem to
support them.
-shared-libgcc: -lgcc_s -lgcc => almost all code uses libgcc_s
-static-libgcc: -lgcc => nothing uses libgcc_s

libgcc.a: contains compiler runtime functions.  I don't really consider
these part of the ABI.
libgcc_s.so: contains most of the functions of libgcc.a and also _Unwind*
functions which are part of the ABI.

clang/clang++ will never use the compiler runtime functions in
libgcc_s.so because it always links with libgcc.a first.

gcc/g++/gfortran link with -L/usr/local/lib/gcc* internally so at
compile time they always use their own libgcc.a and libgcc_s.so.

If you apply my ldconfig patch it will list gcc libgcc_s.so before the
base system libgcc_s.so so you don't have to patch gfortran.

If you apply my gfortran patch it will only need libgcc_s.so for stack
unwinding which our libgcc_s.so handles just fine so you don't need the
ldconfig patch (although it still helps to sort multiple versions of
other gcc runtime libraries).

Either way, our libgcc_s.so only needs to provide _Unwind* and nothing
else.  This doesn't lock FreeBSD to one compiler.

It may be useful to add __float128 functions to our libgcc.a to enable
clang __float128 support.  I haven't looked into that.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Fri, 22 Feb 2019 08:44:54 -0800 Steve Kargl
 wrote:
> On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
>> On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
>>> Do you agree that the ultimate and proper solution is to add missed symbols
>>> and versions to the base libgcc_s.so.1 ?  IMO it is, and this thread started
>>> to show some work which might finally solve that.
>>> (But about as-needed for libgfortran see above).  
>> 
>> Not really no:
>> 
>> 1) GCC can add new symbols or new versions of them with every release
>> which means the problem can reappear with every new GCC release and GCC
>> releases aren't aligned with FreeBSD releases.  
> 
> GCC developers do add new symbols.  Not sure what you mean by
> new versions.  The ABI is stable.  If they change the ABI, then
> they would bump the major number to 2.

The symbol versions like GCC_4.6.0.  The library uses symbol versioning
so they can add new versions of the same symbol without removing the old
versions.  This way adding new versions of a symbol doesn't change the
ABI.

>> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
>> runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
>> these symbols so why should we implement these third party compiler
>> runtime helper functions?  
> 
> Because FreeBSD usurped the name of a well-known library from a
> well-known open source project.  Users might expect that that
> well-known library has the same ABI and functionality of the
> library provided by the well-known project.
> 
> If nothing in base needs /lib/libgcc_s, then let's remove it.
> If nothing in base needs it, let's rename name it to libfreebsd_s.so.

Clang uses the name libgcc_s so clang compiled code can throw exceptions
to gcc compiled code and vice versa.

I suspect that FreeBSD libgcc_s only needs to provide the _Unwind*
symbols and nothing else.  Then it could be renamed to libunwind or
something and then gcc could be patched so its libgcc_s no longer
provides _Unwind* and instead links to the FreeBSD libunwind.  Then
clang also needs to be patched to use libunwind instead of libgcc_s.
It's just easier to keep using the name libgcc_s.  It was perhaps a
mistake of the GCC developers to put compiler runtime functions, which
are compiler specific, and stack unwinding, which is part of the system
ABI that is common to all compilers, in one library.

>> 3) With my gfortran patch you don't need to implement anything.  It's an
>> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD.  
> 
> Your patching a gfortran spec file.  Don't you need to worry
> about the spec file changing, which may invalidate your patch?

Yes, I'll give you that one.  The patch has to be kept up-to-date, but
that's trivial compared to making FreeBSD erratas when a new gcc
release adds a new function to libgcc.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Fri, 22 Feb 2019 09:19:54 -0700 "Russell L. Carter"
 wrote:
> On 2/22/19 6:04 AM, Tijl Coosemans wrote:
>> As for Linux, note that in theory the same problem also exists there.
>> It's just that most Linux distribution only provide one version of gcc.  
> 
> Maybe some distros, but at least for debian-testing, I can install any 
> combo of clang-[678], gcc/g++-[678], and gfortran-[78]

I see.  It looks like they make all these compilers use libgcc from gcc8.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl
 wrote:
> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
>> There's also the fact that gfortran behaves differently from the C
>> compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
>> always links with libgcc_s.  The C compilers link with libgcc.a first
>> and then with libgcc_s only as needed.  
> 
> libgfortran is gfortran's runtime library.  libgcc.a is gcc's 
> runtime library.  The link orders are the same:  libgfortran
> then libgcc_s; libgcc then libgcc_s

No, libgcc is the runtime library for the entire compiler collection not
just the C compiler.  The order of libgcc.a and libgcc_s.so can be
changed with -static-libgcc and -shared-libgcc:

For the C compiler:

default:  libgcc.a -Wl,--as-needed libgcc_s.so -Wl,--no-as-needed
-static-libgcc: libgcc.a
-shared-libgcc: libgcc_s.so libgcc.a

For gfortran:

default: libgcc_s.so libgcc.a (like -shared-libgcc)
-static-libgcc: libgcc.a
-shared-libgcc: libgcc_s.so libgcc.a

What my patch does is change the gfortran default into the C compiler
default.

>> This eliminates almost all
>> links with libgcc_s.  The only ones left are for exception handling
>> and stack unwinding and gcc libgcc_s and base system libgcc_s are
>> version compatible for that so it doesn't matter which one gets picked
>> up.  The attached patch for lang/gcc8 makes gfortran behave just like
>> the C compilers.  
> 
> Just add -static to FFLAGS.  Yep, you're building static
> libraries.
> 
>> We cannot rename the base system libgcc_s to libclang_s because then a
>> process could load both gcc libgcc_s and base system libclang_s and I
>> think that could break exception handling and stack unwinding in weird
>> ways.  
> 
> Wouldn't that be a bug in the program that loads both?

Perhaps yes, but it's same as with missing -rpath.  We don't want to
have to fix those bugs and we don't want users be confronted with them.

> BTW, if you compare gcc trunks symbol map
> ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map
> with src/lib/libgcc_s/Version.map, you'll find that
> that maps are no one-to-one.

Yes, libgcc_s implements stack unwinding and exception handling and
libgcc.a does not.  The stack unwinding and exception handling code has
to be shared so all code in a process uses the same implementation and
accompanying data structures.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
 wrote:
> Yes, we absolutely must avoid situation where two similar libraries
> (i.e. providing some subset of symbols from other) are linked into the
> same executing process.
> 
> I think your patches would be a definitive improvement, esp. the part
> which makes libgfortran linking only as needed.
> 
> For the other part, which makes the ports dso a priority over the base
> dso, I would exercise some more causion. For ports we know only about
> libgcc_s.so.1 which has the same name in base and in ports, other
> libraries in base should have libprivate suffix to not conflict, right ?
> What about openssl libraries ?

As long as libraries have a different name the search order in the
ldconfig cache doesn't matter.  So libfoo.so.x and libprivatefoo.so.x
don't conflict but neither do libfoo.so.x and libfoo.so.y.  Some
libraries in base have the libprivate prefix and they are not meant to
be used by ports at all.  The openssl libraries in base have a different
version suffix than security/openssl* and are allowed to be used by
ports.

> I think such setup makes it easier for user to accidentaly break the system.
> She could install something manually (not from ports), or copy some file
> into /usr/local/lib, which conflicts with base and cause troubles.

Or they could copy something in /lib or /usr/lib and break their system.

The idea behind the ldconfig patch is that the runtime search order
should be as close as possible to a typical compile time order.
Typically compilers and linkers search /usr/local before /usr, so
ldconfig should search /usr/local before /usr.  Anyone that wants a
different order needs to provide a good explanation for that and I don't
think protecting users from shooting themselves in the foot is a good
enough reason.

Similarly, I think our default PATH is also backwards.  Major Linux
distros and MacOS all put /usr/local/bin before /usr/bin.

# User can override sysadmin who can override OS:
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin

> Do you agree that the ultimate and proper solution is to add missed symbols
> and versions to the base libgcc_s.so.1 ?  IMO it is, and this thread started
> to show some work which might finally solve that.
> (But about as-needed for libgfortran see above).

Not really no:

1) GCC can add new symbols or new versions of them with every release
which means the problem can reappear with every new GCC release and GCC
releases aren't aligned with FreeBSD releases.
2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
these symbols so why should we implement these third party compiler
runtime helper functions?
3) With my gfortran patch you don't need to implement anything.  It's an
apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Thu, 21 Feb 2019 10:53:00 -0700 "Russell L. Carter"
 wrote:
> On 2/21/19 10:05 AM, Tijl Coosemans wrote:
>> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce  wrote:  
>>> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:  
>>>> So I must dig deeper.  Perhaps with rpaths interacting with the system
>>>> paths?  
>>>
>>> You got it. ;)
>>> Except python doesn't have an rpath which is why this keeps coming
>>> up over and over again.  
>> 
>> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
>> without depending on gcc.  Then python should use gcc libgcc_s when
>> it exists and fall back to base system libgcc_s when it doesn't.
>> 
>> Maybe we should compile *all* ports with gcc rpaths without depending
>> on gcc, just like we already compile everything with -fstack-protector
>> in LDFLAGS.
> 
> I would like to briefly present the perspective from a user's POV.
> There is a large world wide population of scientific custom code
> users/coders who run on linux boxes in a wide variety of
> configurations.  Almost none of that code will ever have a chance of
> ending up in /usr/ports, although there is nothing technically
> challenging about almost any of it (the porting process that is).  So
> anytime any of those users wants to try running their non-ported
> scientific code, a large fraction of which contains python and/or
> gfortan code, they are going to hit the libgcc_s issue.  Only a few of
> those people understand rpaths as well as I do (and I'm no expert),
> because it's never been their job.  They probably struggle to figure
> out what question to ask, because, "libgcc_s?  WTF?, this is python!"
> In addition, oftentimes people have sometimes big pipelines of
> different programs executing.  So writing a shell script wrapper
> around each and every one of those custom programs... not going to
> happen.  libmap.conf(5)?  Not going to happen.  Linux works out of the
> box.
> 
> People like Steve Kargl and me are... puzzled at why FreeBSD would
> do this to itself.  Having people writing and running custom
> opensource software on a performant opensource OS is **good**.  We
> should be enabling them.

If I were the lang/gcc maintainer this -rpath problem would be my number
one priority.  The current maintainer has never proposed any solutions
and when I submit patches he always resists.  I'm done wasting my time
fighting him.

Then threads like this appear every few months.  It's always the same
people that respond with the same wrong ideas and wrong solutions and
never providing patches.  I always politely point out what's wrong with
their ideas and provide patches that do work.  Then they respond with
the same wrong ideas without even trying my patches.  You can see that
in this very thread.  Rinse, repeat.

It's a people problem, not a technical problem.  My patches solve the
technical problem.  I can't help it if people don't pick up the patches.

As for Linux, note that in theory the same problem also exists there.
It's just that most Linux distribution only provide one version of gcc.
FreeBSD provides multiple versions of multiple compilers and we allow
code compiled with different compilers to be linked together.  Still,
with my patches it should all just work without -rpath.

I can only recommend that you try the patches.  Your Fortran/Python
pipeline will just work like it does on Linux.  I've attached them once
more for your convenience.
Index: libexec/rc/rc.conf
===
--- libexec/rc/rc.conf	(revision 343935)
+++ libexec/rc/rc.conf	(working copy)
@@ -636,14 +636,14 @@ linux_enable="NO"	# Linux binary compatibility loaded 
 clear_tmp_enable="NO"	# Clear /tmp at startup.
 clear_tmp_X="YES" 	# Clear and recreate X11-related directories in /tmp
 ldconfig_insecure="NO"	# Set to YES to disable ldconfig security checks
-ldconfig_paths="/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg"
+ldconfig_paths="/usr/local/lib /usr/local/lib/compat/pkg /usr/lib /usr/lib/compat /lib"
 			# shared library search paths
 ldconfig32_paths="/usr/lib32 /usr/lib32/compat"
 			# 32-bit compatibility shared library search paths
-ldconfigsoft_paths="/usr/libsoft /usr/libsoft/compat /usr/local/libsoft"
+ldconfigsoft_paths="/usr/local/libsoft /usr/libsoft /usr/libsoft/compat"
 			# soft float compatibility shared library search paths
 			# Note: temporarily with extra stuff for transition
-ldconfig_paths_aout="/usr/lib/compat/aout /usr/local/lib/aout"
+ldconfig_paths_aout="/usr/local/lib/aout /usr/lib/aout /usr/lib/compat/aout"
 			# a.out shared library search paths
 ldconfig_local_dirs="

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Thu, 21 Feb 2019 16:13:15 -0800 Steve Kargl
 wrote:
> On Thu, Feb 21, 2019 at 11:18:50PM +0100, Tijl Coosemans wrote:
>> On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce  wrote:
>>> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
>>>> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce  wrote:
>>>>> Except python doesn't have an rpath which is why this keeps coming
>>>>> up over and over again.
>>>> 
>>>> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
>>>> without depending on gcc.  Then python should use gcc libgcc_s when
>>>> it exists and fall back to base system libgcc_s when it doesn't.
>>> 
>>> Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed
>>> a specific port will require a fortran built binary module later.
>>> 
>>>> Maybe we should compile *all* ports with gcc rpaths without depending
>>>> on gcc, just like we already compile everything with -fstack-protector
>>>> in LDFLAGS.
>>>> 
>>>> There's also the fact that gfortran behaves differently from the C
>>>> compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
>>>> always links with libgcc_s.  The C compilers link with libgcc.a first
>>>> and then with libgcc_s only as needed.  This eliminates almost all
>>> 
>>> What is really happening is gfortran links with libgfortran (surprise
>>> surprise) and libgfortran has the requirement for @GCC_4.6.0 or later
>>> 
>>>> links with libgcc_s.  The only ones left are for exception handling
>>>> and stack unwinding and gcc libgcc_s and base system libgcc_s are
>>>> version compatible for that so it doesn't matter which one gets picked
>>>> up.  The attached patch for lang/gcc8 makes gfortran behave just like
>>>> the C compilers.
>>> 
>>> Something like this was tried already. I'll have to dig into
>>> my old notes.
>> 
>> With my patch libgfortran only needs GCC_4.2.0 and works with base
>> libgcc_s.
> 
> Why not bump the major version number of the port?

Because that renames the library and like I said, renaming allows a
process to load both versions, as your example shows.

> % ~/work/x/bin/gfortran -o z hello.f90
> % ldd z
> z:
> libgfortran.so.5 => /usr/local/lib/gcc8/libgfortran.so.5 (0x20080)
> libm.so.5 => /lib/libm.so.5 (0x200645000)
> libgcc_s.so.2 => /safe/sgk/work/x/lib/libgcc_s.so.2 (0x200c58000)
> libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x200e7)
> libc.so.7 => /lib/libc.so.7 (0x2010b)
> libz.so.6 => /lib/libz.so.6 (0x200678000)
> libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x2014a1000)
> %  nm z | grep 4.6
>  U __multf3@@GCC_4.6.0
> % ./z
>2.000
> 
> Note, I'm playing with a test install into a ~/work/x directory.
> The ldconfig still has issues with first come first served
> 
> % ldconfig -r | grep libgcc_s
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 806:-lgcc_s.1 => /usr/local/lib/gcc8/libgcc_s.so.1
> 880:-lgcc_s.2 => /safe/sgk/work/x/lib/libgcc_s.so.2
> %  ldconfig -r | grep libgfortran
> 808:-lgfortran.5 => /usr/local/lib/gcc8/libgfortran.so.5
> 876:-lgfortran.5 => /safe/sgk/work/x/lib/libgfortran.so.5
> 
> 6 is picked up due to libc.so.  806 is picked up due to
> 808, but won't be there is major version number is
> bumped.  876 is the loser of the first come first served, here;
> but 808 would be the correct libgfortran point to 880 if I
> had installed into /usr/local/lib/gcc8.

The ldconfig order can be improved.  I've attached another patch that
I've been using for a long time.  It changes /etc/rc.d/ldconfig so it
puts /usr/lib and /lib last, just like compilers and linkers do at
compile time, and as documented in rtld(1).  It also sorts paths like
/usr/local/lib/gcc(7|8|9|10) in reverse version order so if multiple
versions are installed the most recent libgcc_s is listed first.

> PS: For the record, the GCC_4.6.0 are needed for gfortran REAL(16)
> type.

With my patch gfortran resolves the GCC_4.6.0 symbols statically just
like the C compilers do.  If the C compilers didn't do this we'd have
this libgcc_s problem all over the place.  It makes perfect sense to
make gfortran do the same thing.
Index: libexec/rc/rc.conf
===
--- libexec/rc/rc.conf	(revision 343935)
+++ libexec/rc/rc.conf	(working copy)
@@ -636,14 +636,14 @@ linux_enable="NO"	

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce  wrote:
> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
>> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce  wrote:  
>>> Except python doesn't have an rpath which is why this keeps coming
>>> up over and over again.  
>> 
>> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
>> without depending on gcc.  Then python should use gcc libgcc_s when
>> it exists and fall back to base system libgcc_s when it doesn't.  
> 
> Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed
> a specific port will require a fortran built binary module later.
> 
>> Maybe we should compile *all* ports with gcc rpaths without depending
>> on gcc, just like we already compile everything with -fstack-protector
>> in LDFLAGS.
>> 
>> There's also the fact that gfortran behaves differently from the C
>> compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
>> always links with libgcc_s.  The C compilers link with libgcc.a first
>> and then with libgcc_s only as needed.  This eliminates almost all  
> 
> What is really happening is gfortran links with libgfortran (surprise 
> surprise) and libgfortran has the requirement for @GCC_4.6.0 or later
> 
>> links with libgcc_s.  The only ones left are for exception handling
>> and stack unwinding and gcc libgcc_s and base system libgcc_s are
>> version compatible for that so it doesn't matter which one gets picked
>> up.  The attached patch for lang/gcc8 makes gfortran behave just like
>> the C compilers.  
> 
> Something like this was tried already. I'll have to dig into
> my old notes. 

With my patch libgfortran only needs GCC_4.2.0 and works with base
libgcc_s.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce  wrote:
> On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
>> So I must dig deeper.  Perhaps with rpaths interacting with the system
>> paths?
> 
> You got it. ;)
> Except python doesn't have an rpath which is why this keeps coming
> up over and over again.

Maybe we should just add the gcc rpaths to the python ports LDFLAGS
without depending on gcc.  Then python should use gcc libgcc_s when
it exists and fall back to base system libgcc_s when it doesn't.

Maybe we should compile *all* ports with gcc rpaths without depending
on gcc, just like we already compile everything with -fstack-protector
in LDFLAGS.

There's also the fact that gfortran behaves differently from the C
compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
always links with libgcc_s.  The C compilers link with libgcc.a first
and then with libgcc_s only as needed.  This eliminates almost all
links with libgcc_s.  The only ones left are for exception handling
and stack unwinding and gcc libgcc_s and base system libgcc_s are
version compatible for that so it doesn't matter which one gets picked
up.  The attached patch for lang/gcc8 makes gfortran behave just like
the C compilers.

We cannot rename the base system libgcc_s to libclang_s because then a
process could load both gcc libgcc_s and base system libclang_s and I
think that could break exception handling and stack unwinding in weird
ways.
Index: lang/gcc8/files/patch-gcc_fortran_gfortranspec.c
===
--- lang/gcc8/files/patch-gcc_fortran_gfortranspec.c	(nonexistent)
+++ lang/gcc8/files/patch-gcc_fortran_gfortranspec.c	(working copy)
@@ -0,0 +1,11 @@
+--- gcc/fortran/gfortranspec.c.orig	2018-01-03 10:03:58 UTC
 gcc/fortran/gfortranspec.c
+@@ -404,7 +404,7 @@ warranty; not even for MERCHANTABILITY or FITNESS FOR 
+ 	}
+ }
+ 
+-#ifdef ENABLE_SHARED_LIBGCC
++#if 0
+   if (library)
+ {
+   unsigned int i;

Property changes on: lang/gcc8/files/patch-gcc_fortran_gfortranspec.c
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: lang/gcc8/files/patch-libgfortran_Makefile.in
===
--- lang/gcc8/files/patch-libgfortran_Makefile.in	(nonexistent)
+++ lang/gcc8/files/patch-libgfortran_Makefile.in	(working copy)
@@ -0,0 +1,11 @@
+--- libgfortran/Makefile.in.orig	2018-07-26 09:48:58 UTC
 libgfortran/Makefile.in
+@@ -625,7 +625,7 @@ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
+ 	$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
+ 	$(HWCAP_LDFLAGS) \
+ 	-lm $(extra_ldflags_libgfortran) \
+-	$(version_arg) -Wc,-shared-libgcc
++	$(version_arg)
+ 
+ libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
+ cafexeclib_LTLIBRARIES = libcaf_single.la

Property changes on: lang/gcc8/files/patch-libgfortran_Makefile.in
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Building qt5-gui port?

[Tijl Coosemans]

On Sun, 10 Feb 2019 15:18:20 -0800 Steve Kargl
 wrote:
> On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
>> 
>> /usr/ports/Mk/Uses/qt-dist.mk has:
>> 
>> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
>> CONFIGURE_ARGS+=-no-sse2
>> .endif
> 
> Hmmm.  Oh well.  I set CPUTYPE=core2 in /etc/make.conf.
> During configure of qt5-gui, it does try to use sse2,
> sse3, ssse3, and even the unsupported avx.  The build
> still dies.

You probably need to build all of Qt with the same flags, starting
with qt5-qmake and then the other dependencies of qt5-gui.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: japanese/libreoffice build failed (13.0-CURRENT/r339677)

[Tijl Coosemans]

On Fri, 23 Nov 2018 17:00:05 +0900 KIRIYAMA Kazuhiko  
wrote:
> I've update to r485516 and build japanese/libreoffice
> again. Result was perfect! I've built with 'make
> package-recursive' and all packages depends it had created
> completely [1]. Thanks for maintaining japanese/libreoffice :-)
> 
> P.S.
>   This port need graphics/mesa-libs with
> PYTHON_VERSION=python2.7. libreoffice need BUILD_DEPENDS
> this ?

I guess for some 3D effects in Impress, but I'm not the libreoffice
maintainer so I don't really know.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: japanese/libreoffice build failed (13.0-CURRENT/r339677)

[Tijl Coosemans]

On Wed, 14 Nov 2018 21:06:37 +0900 KIRIYAMA Kazuhiko  
wrote:
> er-statement -Wvla -Wpointer-arith -Wmissing-declarations 
> -Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings 
> -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs 
> -Waddress -Wno-multichar -Wnested-externs -g -fvisibility=hidden -O2 -pipe 
> -Wno-format -fstack-protector -fno-strict-aliasing -MT 
> libgstgl_wayland_la-gstgldisplay_wayland.lo -MD -MP -MF 
> .deps/libgstgl_wayland_la-gstgldisplay_wayland.Tpo -c gstgldisplay_wayland.c  
> -fPIC -DPIC -o .libs/libgstgl_wayland_la-gstgldisplay_wayland.o
> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I../../../.. -I/usr/local/include 
> -I../../../../gst-libs -I../../../../gst-libs -I/usr/local/include 
> -D_THREAD_SAFE -pthread -I/usr/local/include -I/usr/local/include 
> -I/usr/local/include/libdrm -D_THREAD_SAFE -pthread -I../../../../gst-libs 
> -I../../../../gst-libs -I/usr/local/include/gstreamer-1.0 
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -I/usr/local/include -pthread -I/usr/local/include/glib-2.0 
> -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread 
> -I/usr/local/include/gstreamer-1.0 -I/usr/local/include/glib-2.0 
> -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread 
> -fno-strict-aliasing -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -Wall 
> -Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations 
> -Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings 
> -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs 
> -Waddress -Wno-multichar -Wnested-externs -!
 g !
>  -fvisibility=hidden -O2 -pipe -Wno-format -fstack-protector 
> -fno-strict-aliasing -MT libgstgl_wayland_la-wayland_event_source.lo -MD -MP 
> -MF .deps/libgstgl_wayland_la-wayland_event_source.Tpo -c 
> wayland_event_source.c  -fPIC -DPIC -o 
> .libs/libgstgl_wayland_la-wayland_event_source.o
> libtool: compile:  cc -DHAVE_CONFIG_H -I. -I../../../.. -I/usr/local/include 
> -I../../../../gst-libs -I../../../../gst-libs -I/usr/local/include 
> -D_THREAD_SAFE -pthread -I/usr/local/include -I/usr/local/include 
> -I/usr/local/include/libdrm -D_THREAD_SAFE -pthread -I../../../../gst-libs 
> -I../../../../gst-libs -I/usr/local/include/gstreamer-1.0 
> -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include 
> -I/usr/local/include -pthread -I/usr/local/include/glib-2.0 
> -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread 
> -I/usr/local/include/gstreamer-1.0 -I/usr/local/include/glib-2.0 
> -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread 
> -fno-strict-aliasing -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -Wall 
> -Wdeclaration-after-statement -Wvla -Wpointer-arith -Wmissing-declarations 
> -Wmissing-prototypes -Wredundant-decls -Wundef -Wwrite-strings 
> -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs 
> -Waddress -Wno-multichar -Wnested-externs -!
 g !
>  -fvisibility=hidden -O2 -pipe -Wno-format -fstack-protector 
> -fno-strict-aliasing -MT libgstgl_wayland_la-gstglwindow_wayland_egl.lo -MD 
> -MP -MF .deps/libgstgl_wayland_la-gstglwindow_wayland_egl.Tpo -c 
> gstglwindow_wayland_egl.c  -fPIC -DPIC -o 
> .libs/libgstgl_wayland_la-gstglwindow_wayland_egl.o
> gstglwindow_wayland_egl.c:28:10: fatal error: 'linux/input.h' file not found
> #include 
>  ^~~
> 1 error generated.
> gmake[9]: *** [Makefile:731: libgstgl_wayland_la-gstglwindow_wayland_egl.lo] 
> Error 1
> gmake[9]: *** Waiting for unfinished jobs
> mv -f .deps/libgstgl_wayland_la-gstgldisplay_wayland.Tpo 
> .deps/libgstgl_wayland_la-gstgldisplay_wayland.Plo
> mv -f .deps/libgstgl_wayland_la-wayland_event_source.Tpo 
> .deps/libgstgl_wayland_la-wayland_event_source.Plo
> gmake[9]: Leaving directory 
> '/var/ports/work/usr/ports/multimedia/gstreamer1-plugins/work/gst-plugins-base-1.14.4/gst-libs/gst/gl/wayland'
> gmake[8]: *** [Makefile:1279: all-recursive] Error 1
> gmake[8]: Leaving directory 
> '/var/ports/work/usr/ports/multimedia/gstreamer1-plugins/work/gst-plugins-base-1.14.4/gst-libs/gst/gl'
> gmake[7]: *** [Makefile:659: all-recursive] Error 1
> gmake[7]: Leaving directory 
> '/var/ports/work/usr/ports/multimedia/gstreamer1-plugins/work/gst-plugins-base-1.14.4/gst-libs/gst'
> gmake[6]: *** [Makefile:624: all-recursive] Error 1
> gmake[6]: Leaving directory 
> '/var/ports/work/usr/ports/multimedia/gstreamer1-plugins/work/gst-plugins-base-1.14.4/gst-libs'
> gmake[5]: *** [Makefile:746: all-recursive] Error 1
> gmake[5]: Leaving directory 
> '/var/ports/work/usr/ports/multimedia/gstreamer1-plugins/work/gst-plugins-base-1.14.4'
> gmake[4]: *** [Makefile:677: all] Error 2
> gmake[4]: Leaving directory 
> '/var/ports/work/usr/ports/multimedia/gstreamer1-plugins/work/gst-plugins-base-1.14.4'
> ===> Compilation failed unexpectedly.  
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> 

Re: Inkscape compiles but crashes on startup

[Tijl Coosemans]

On Sat, 3 Nov 2018 22:31:34 -0700 bob prohaska  wrote:
> On Sat, Nov 03, 2018 at 07:18:52AM +0100, Walter Schwarzenfeld wrote:
>> Wait, fix of the primal cause of it is committed right now.
>> 
>> https://svnweb.freebsd.org/ports?view=revision=483878
> 
> Alas, no luck. Updating the ports tree and recompiling inkscape got
> rid of the locale error, but inkscape still crashes with an otherwise
> similar error stream from Gtk.

You have to rebuild devel/glib20.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Firefox constantly trashing disk

[Tijl Coosemans]

On Fri, 14 Sep 2018 18:13:57 +0200 Andrea Venturoli  wrote:
> Hello.
> 
> I think FireFox (ESR) on my system makes really too much disk I/O.
> My profile is on an NFS drive, but I hear local disks spinning, so I 
> guess it's writing to /tmp or /var/tmp (or another local folder).
> 
> Looks like animations are what really make him go mad: just opening 
> https://get.webgl.org/ will start heavy disk activity which will only 
> stop when that page is closed; however even a simple gallery, where 
> images "slide" smoothly, will give a spin any time a button is pressed 
> and the image changes.
> 
> I'd like to dig into this and understand what it is doing.
> 
> Is there a way I can see what file Firefox is writing too?
> I tried "lsof|grep firefox", but that will list some 1200-1300 entries 
> and I still don't know which is the one.

Try the patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222356
For Firefox ESR you may need the version hidden behind 'Show Obsolete'.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: DEFAULT_VERSIONS=gcc=8 results in gfortran7

[Tijl Coosemans]

On Fri, 17 Aug 2018 10:24:53 + Anton Shterenlikht  wrote:
> I got no replies from fortran@, reposting here.
> 
> I'm building with synth.
> jrmarino says this should work,
> i.e. the problem is not in synth.
> 
> I have DEFAULT_VERSIONS=gcc=8 in synth make.conf:
> 
> # cat /usr/local/etc/synth/LiveSystem-make.conf 
> DEVELOPER=yes
> FFLAGS+= -O2 -pipe -march=bdver2 -mtune=bdver2
> FFLAGS+= -funroll-loops --param max-unroll-times=4 -ftree-vectorize
> FFLAGS+= -g
> DEFAULT_VERSIONS=gcc=8
> 
> However, when building net/mpich, gfortran7 is used:
> 
> --
> --  CONFIGURE_ENV
> --
> PKG_CONFIG=pkgconf
> F77="gfortran7"
> FC="gfortran7"
> 
> Here's the full log:
> 
> http://cmplx.uk/net___mpich.log
> 
> Should setting DEFAULT_VERSIONS=gcc=8 in make.conf
> be sufficient to force the use of gfortran8?
> 
> Looking at /usr/ports/Mk/Uses/fortran.mk, my answer is yes.

"make DEFAULT_VERSIONS=gcc=8 -V FC" prints gfortran8 here so it should
work.  Make sure you don't set DEFAULT_VERSIONS elsewhere and that the
make.conf is actually used (insert a .error directive or something and
check that it fails).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Automake creation error.. generic or just me?

[Tijl Coosemans]

On Wed, 25 Jul 2018 22:43:05 +0800 Julian Elischer  wrote:
> I'm not exactly sure where the error come from.. possibly the find, if 
> stderr and stdout are not synchronous.
> 
> Has anyone else seen this?  or understand it?
> 
> 
> ===>  Building for automake-1.16.1  
> --- doc/aclocal.1 ---
> --- doc/automake.1 ---
> --- bin/automake ---
> 
> [...]ls pkg/All
> 
> /usr/bin/make  install-data-hook
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver'
>   chmod +x 
> '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh'
> find: 
> /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: No 
> such file or directory
> > Compressing man pages (compress-man)
> ===>  Installing for automake-1.16.1
> ===>   Registering installation for automake-1.16.1 as automatic  
> *** Error code 70

Possibly caused by 
https://svnweb.freebsd.org/ports?view=revision=473539
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"