Re: net/libarcus fails to install

[Diane Bruce]

On Wed, Dec 30, 2020 at 11:01:05AM +1030, Shane Ambler wrote:
> On 28/12/20 4:40 am, Torfinn Ingolfsen wrote:
> > On Sun, Dec 27, 2020 at 2:41 PM Torfinn Ingolfsen  wrote:
> >>
> >> net/libarcus builds, but fails to install:
> 
> > FWIW, devel/libsavitar has the same "problem"; with python38 installed
> > it fails to install because it builds for 3.8 instead of 3.7.
> 
> The issue is in cmake - I have just reported it as a bug
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252277

Thanks for tracking this down! This bug of course fails to show
up on poudriere.

> 
> For a workaround try adding the following to the end of the libarcus
> Makefile (above the last .include line) indents are tabs not spaces
> The same addition should also work for libsavitar
> 
> post-patch:
>   ${REINPLACE_CMD} -e 's|VERSION_LESS 3.12|VERSION_LESS 4.12|g' \
>   ${WRKSRC}/CMakeLists.txt \
>   ${WRKSRC}/cmake/FindSIP.cmake
> 

Should we do this for now? Or wait for CMake to be fixed?
I can certainly add this snippet to the port for now.



> 
> -- 
> FreeBSD - the place to B...Software Developing
> 
> Shane Ambler
> 
> ___
> 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"

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: qrc:/Desktop.qml:26 module "QtQuick.Dialogs" is not installed

[Diane Bruce]

On Fri, Apr 03, 2020 at 08:44:14AM +0200, Wojciech Puchar wrote:
> what package am i missing?

Try x11-toolkits/qt5-quickcontrols

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: category for VPN softwares?

[Diane Bruce]

On Tue, Apr 02, 2019 at 06:13:58AM -0600, Adam Weinberger wrote:
> On Tue, Apr 2, 2019 at 3:37 AM Mateusz Piotrowski <0...@freebsd.org> wrote:
> >
> > On Tue, 2 Apr 2019 at 10:58, Stefan Esser  wrote:
> >
> > > Am 02.04.19 um 07:42 schrieb Koichiro Iwao:
> > > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote:
> > > >> Create a real category vpn and move everything to it ?
> > > >
> > > > Sounds better! Gentoo has net-vpn category. Just FYI, Gentoo also have
> > > > net-dialup category. PPP/PPPoE/L2TP softwares are put under net-dialup
> > > > but I feel that classification is too fine. At least creating vpn or
> > > > net-vpn souds good.
> > >
> > > How about a new "real" category vpn
> >
> >
> > I am not sure if it should be vpn or net-vpn. I feel net-vpn is
> > more suitable.
> >
> >
> > > and preserving the current categories
> > > of the ports as their additional categories (assuming that they are in net
> > > vs. security for a reason).
> > >
> >
> > I like the idea.
> 
> Creating new categories is absolutely doable! However, we have a
> pretty high bar for justifying it. There's no magic number, but our
> (portmgr's) precedent is that the new category must, at the time of
> creation, be as full as other categories like it.
> 
> The most important thing in the new category proposal is a
> comprehensive list of ports that will be moved to it. Put that into a
> review or a PR and we can move forward. Fair warning though, if it's
> only about a dozen ports, it most likely will not be approved.
> 
> My approach here is that new categories should be virtual unless the
> evidence for hard category is incontrovertible.

It's far easier making a virtual category and easier to count ports.
e.g. https://www.freshports.org/hamradio 

We have 101 hamradio related ports with more coming...
korean has 43,portuguese has 15,russian has 42 although languages are a
special case palm has 15 ports but whatever. ;)

I'd be surprised if there weren't more vpn ports than 101 so why not
go with a virtual ports category to start with? 

> 
> # Adam
> 
> 
> -- 
> Adam Weinberger
> ad...@adamw.org
> https://www.adamw.org
> ___
> 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"

-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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: category for VPN softwares?

[Diane Bruce]

On Tue, Apr 02, 2019 at 11:38:15AM +0200, Mateusz Piotrowski wrote:
> On Tue, 2 Apr 2019 at 10:58, Stefan Esser  wrote:
> 
> > Am 02.04.19 um 07:42 schrieb Koichiro Iwao:
> > > On Tue, Apr 02, 2019 at 06:41:51AM +0200, Kurt Jaeger wrote:
> > >> Create a real category vpn and move everything to it ?
...

...
> 
> > and preserving the current categories
> > of the ports as their additional categories (assuming that they are in net
> > vs. security for a reason).
> >
> 
> I like the idea.

Hey if you can convince port managers that a new real category is in
order I'll petition for a real hamradio category. We are currently
split between audio, comms, misc, cad ... ;)

It will be much easier getting a new virtual category than a real category.
I'd agree a real category for both vpn and hamradio would be nice but
it's a PITA and personally I don't feel it matters that much.

-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

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?
> > >
> >
> > Dave,
> >
> > 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
> http://users.ox.ac.uk/~coml0531/

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. 


> 
> >
> > --
> > Steve

Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

On Thu, Feb 21, 2019 at 01:46:46PM -0800, Steve Kargl wrote:
> On Thu, Feb 21, 2019 at 01:30:41PM -0500, Diane Bruce wrote:
> > 
> > Yes yes and yes. It would be a right PITA. Perhaps it could be done
> > with some weak symbols but personally I think that's another hack.
> > I'll go look for whatever symbols we are missing and see if we
> > can fix our libgcc_s
> > 
>  
> Diane,
> 
> The missing symbols are
> 
> % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
> 
> __addtf3@@GCC_4.6.0
> __divtf3@@GCC_4.6.0
> __eqtf2@@GCC_4.6.0
> __floatditf@@GCC_4.6.0
> __floatsitf@@GCC_4.6.0
> __floatunditf@@GCC_4.6.0
> __getf2@@GCC_4.6.0
> __gttf2@@GCC_4.6.0
> __letf2@@GCC_4.6.0
> __lttf2@@GCC_4.6.0
> __multf3@@GCC_4.6.0
> __netf2@@GCC_4.6.0
> __subtf3@@GCC_4.6.0
> __unordtf2@@GCC_4.6.0
> 
> It looks like we may be able to grab some of these from libc/softfloat:
> getf2.c, gttf2.c, letf2.c, lttf2.c, netf2.c.
> 
> It looks like we might be able to grab a few more from NetBSD:
> eqtf2.c and unordtf2.c
> 
> -- 
> steve

Thank you.

Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

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:
> > 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.

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. 

> 
> 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.

Yes yes and yes. It would be a right PITA. Perhaps it could be done
with some weak symbols but personally I think that's another hack.
I'll go look for whatever symbols we are missing and see if we
can fix our libgcc_s

...

Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

On Sun, Feb 17, 2019 at 10:42:03PM +0700, Eugene Grosbein wrote:
> 17.02.2019 22:15, Diane Bruce wrote:
> 
> > Basically all we need is a pre-loader script for interpreters
...
> 
> We already have libmap.conf(5). It should be possible to work around the 
> problem
> creating /usr/local/etc/libmap.d/python.conf with contents:
> 
> [python2.7]
> libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1
> 
> [python3.4]
> libgcc_s.so.1 /usr/local/lib/gcc8/libgcc_s.so.1
> 

Sure but I'm guessing not all python ports *need* gfortran hence
we shouldn't force all python coded ports to use the gfortran libgcc_s.so
Moreover, the libmap would have to be updated everytime gfortran got
updated which is true for the PRELOAD script but at least it
would be with the port, not system wide. 

That's my two Canadian cents. (We don't even have pennies anymore up here ;) )

- Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote:
> 17.02.2019 8:02, Russell L. Carter wrote:
> 
> > Greetings,
> > 
> > Restarting the FreeCAD 0.17 discussion on a different tangent.
> > 
...
> > /usr/local/lib/gcc8/libgfortran.so.5 not found
> > 
> > This is probably fatal to practical use of FreeCAD on FreeBSD.  I was
> > able to open most of my previous models, created on debian-testing,
> > but some were fail.
> > 
> > 2 threads, no happy ending:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113336.html
> > https://lists.freebsd.org/pipermail/freebsd-python/2016-January/009672.html
> > 
> > Question to experienced porters, how is this best practice solved?

I've just updated my wiki entry. I think the old entry was way too
long so the TLDR; solution I suggest comes first

https://wiki.freebsd.org/libgcc%20problem#preview

The problem is simple. Python code is not linked with libgcc_s
so the system 'fake' libgcc_s is preferred over the one that Fortran
prefers since python doesn't 'know' about gfortran at all no RPATH
is ever seen in time. Hence if a python binary module is loaded that does use 
libgcc_s.so it's the system libgcc_s not the one that Fortran "needs".

> 
> I've just did "pkg install gcc8" using my FreeBSD 11.2/amd64 system and got 
> this:
> 
> # ldd /usr/local/lib/gcc8/libgfortran.so.5
> /usr/local/lib/gcc8/libgfortran.so.5:
> libquadmath.so.0 => /usr/local/lib/gcc8/libquadmath.so.0 (0x80146e000)
> libz.so.6 => /lib/libz.so.6 (0x8016ad000)
> libm.so.5 => /lib/libm.so.5 (0x8018c5000)
> libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x801af3000)
> libc.so.7 => /lib/libc.so.7 (0x800823000)
> 
> So, /usr/local/lib/gcc8/libgfortran.so.5 does not depend on /lib/libgcc_s.so.1
> but on /usr/local/lib/gcc8/libgcc_s.so.1 in normal case.
> 
> I assume something is broken in your installation. Try removing gcc8 and 
> reinstalling
> it using package.

No, it's as I outlined above. I have a possible longer term
transparent workaround I've mentioned to @emaste but it will take
some trivial port changes.

Basically all we need is a pre-loader script for interpreters
that run into this such as python. (I suspect there have to be other
interpreters that run into this.) Perhaps something like 
python2_gfortran or the like, all it has to do is PRELOAD or modify
the library path  so we get the 'right' libgcc_s.so.


- Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
> On 2/16/19 6:21 PM, Eugene Grosbein wrote:
> > 17.02.2019 8:02, Russell L. Carter wrote:
> > 
> >> Greetings,
...
> root@feyerabend>
> 
> So I must dig deeper.  Perhaps with rpaths interacting with the system
> paths?
> 
> Russell

You got it. ;)
Except python doesn't have an rpath which is why this keeps coming
up over and over again.

- Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

On Sun, Feb 17, 2019 at 01:35:31PM +0700, Eugene Grosbein wrote:
> 17.02.2019 13:19, Steve Kargl wrote:
> 
> > For whatever reason, there are situations where the rpath
> > isn't set in the library.  Read the rtld manpage.  You're
> > hitting #5 in the list.
> 
> Our package building system sets rpath for dependants of gcc8,
> so Fortran libraries (and others) do have rpath for its runtime.
> 
> Setting rpath for resulting binary should solve the problem.

No no no no no. Not for an interpreter. The interpreter doesn't 'know'
you are about to load a binary module that needs libgcc_s and until
it loads something that uses gfortran it doesn't matter
which libgcc_s so it picks the 'wrong' one.

As my wiki page article says: 
We can rename our libgcc (Yes other complications but...)

We can fix our system libgcc to have the missing functions/data that
current libgcc has then bump our version

We can use a specific port which PRELOADs the gfortran libgcc_s.so
e.g. python2_gfortran8 or whatever. (What a mess and it's ugly but
it would work)

Individual python ports could be modified to do the PRELOAD with
a tiny sh script e.g. opencad could envoke a small sh script
that then starts the python interpreter. This would mean exposing the
PATH from Mk/USES/fortan.mk

e.g. we currently do this:

FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \

We'd need FRPATH=${LOCALBASE}/lib/gcc${_GCC_VER}
exposed

blah. I finally just looked at openscad it's a binary not a python script
As Steve sez it's missing the -Wl,-rpath stuff then

- Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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

[Diane Bruce]

On Sat, Feb 16, 2019 at 09:56:55PM -0800, Steve Kargl wrote:
> On Sun, Feb 17, 2019 at 12:37:36PM +0700, Eugene Grosbein wrote:
> > 17.02.2019 12:11, Steve Kargl wrot:
> > 
> > > 
> > > There is a problem with the order of libgcc_s.so.1
> > > in the cache created by ldconfig.  rtld will use
...

> 4) bump the major library version number for /lib/libgcc.so.1
>to 2;
> 5) fix rtld to not fail on the first found library in the cache.
>Iterated over all entries and only fail if the library isn't found;

Not so easy. I looked at it but it would not be easy. 

> 6) rename /lib/libgcc_s.so.1 to /lib/libllvm_s.so.1 and teach
>llvm/clang/rtld to not misappropriate a well-known GCC library
>name.

For the record I have been arguing for this for a few years as well.

Read my wiki page on it.

- Diane
-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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: Strange interaction between py-pyglet and py-numpy

[Diane Bruce]

On Mon, Nov 26, 2018 at 11:59:36PM +, Montgomery-Smith, Stephen wrote:
> Using python2.7, if I run this code:
> 
> import numpy as np
> from pyglet.gl import *
> 
> everything works fine.  But if I put the same code in the other order:
> 
> from pyglet.gl import *
> import numpy as np
> 
> I get:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.7/site-packages/numpy/__init__.py", line
> 142, in 
> from . import add_newdocs
>   File "/usr/local/lib/python2.7/site-packages/numpy/add_newdocs.py",
> line 13, in 
> from numpy.lib import add_newdoc
>   File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py",
> line 8, in 
> from .type_check import *
>   File "/usr/local/lib/python2.7/site-packages/numpy/lib/type_check.py",
> line 11, in 
> import numpy.core.numeric as _nx
>   File "/usr/local/lib/python2.7/site-packages/numpy/core/__init__.py",
> line 26, in 
> raise ImportError(msg)
> ImportError:
> Importing the multiarray numpy extension module failed.  Most
> likely you are trying to import a failed build of numpy.
> If you're working with a numpy git repo, try `git clean -xdf` (removes all
> files not under version control).  Otherwise reinstall numpy.
> 
> Original error was: /lib/libgcc_s.so.1: version GCC_4.8.0 required by
> /usr/local/lib/gcc7/libgfortran.so.4 not found
> 
> 
> Any ideas?


I want my pony still.

https://wiki.freebsd.org/libgcc%20problem


> ___
> 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"

-- 
- d...@freebsd.org d...@db.net http://artemis.db.net/~db
___
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: Do you support creation of "chemistry" and "physics" virtual categories?

[Diane Bruce]

On Mon, Jul 30, 2018 at 01:07:07AM -0700, Yuri wrote:
...
> 
> Do you support creation of "chemistry" and "physics" virtual categories?

Of course. Have fun!

> 
> 
> Thanks,
> 
> Yuri
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Runtime loader issue

[Diane Bruce]

On Thu, May 10, 2018 at 08:15:22AM -0700, Steve Kargl wrote:
> On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> > On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:
> > > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> > > s...@troutmask.apl.washington.edu> wrote:
> > > 
...
> > 
> > Yep.
> > See https://wiki.freebsd.org/libgcc%20problem
> > 
> 
> Interesting page.  I was aware that in the past you tried working
> out a solution to the problem.  I did not realize you docoumented
> the issue.  A few corrections to your wiki page.
> 
> 1) The correct spelling of the name of the language is Fortran (with a
>capital F).  It has been the official standard spelling since Fortran
>90.

Fixed

> 
> 2) You have "... to always support quad math (*8) and ...".  Quad
>precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard).

I think I got it right this time...
> 
> 3) "subsitute" is normally spelled with an extra 't'. :-)

OOOps ;) fixed
 
> > Very ;)
> 
> Just started reading the source code.  Don't scare the unwary. :-)

;)

> 
> -- 
> Steve

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Runtime loader issue

[Diane Bruce]

On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote:
> On Thu, May 10, 2018 at 2:45 AM, Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
> 
> > In review PR 228007, it came to my attention some individuals are
> > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD
> > issue".  See

Indeed. I've tried to make it clear it is a name conflict with libgcc
in my own bug reports on the subject.

> >
> > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html
> >
> > The problem can be summarized by the following
...
> > gfortran7 is installed from ports/lang/gcc7.  This is not
> > a "gfortran's FreeBSD issue".  This is a FreeBSD loader issue.
> >
> > Specifically, there is a shared library name clash.
> >
> > % ldconfig -r | grep gcc_
> >  6:-lgcc_s.1 => /lib/libgcc_s.so.1
> >716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1

Yep.
See https://wiki.freebsd.org/libgcc%20problem

> >
> > So, the runtime loader finds 6 instead of 716, tries to link,
> > fails, and issues an error message.  There are a number ways to
> > fix this issue.
> >
> > 1) By far, the best solution would be to stop hijacking the libgcc
> >name in libraries installed on FreeBSD that are not related to
> >actual GCC software.

Agreed, however this has the side effect of meaning conflicts with libraries
between clang and gcc libs. Notably gfortran and flang use different
conventions for I/O :(

See http://people.FreeeBSD.org/~db/fortran_libs.txt

> >
> >Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)?  Yes, I'm
> >aware that clang does not work on all archs and the ancient gcc
> >lives on.
> >

I've argued for this as well and frankly I still think it is the best
solution all around. 

> > 2) Given the expected push back againt solution 1), this solution
> >proposes bumping the library version for /lib/libgcc_s.so.1 from
> >1 to some larger value, say, 10.  It is unlikely that GCC will
> >bump its shared library number anytime soon.  GCC bumped it from
> >0 to 1 some 16 years ago.
> >
> >https://gcc.gnu.org/viewcvs/gcc?view=revision=43316
> >
> >This solution, however, papers over the general problem with
> >name clashes.

Yep. I know work is slowly being done to modernise our libgcc already
but the toolchain folks are busy...

> >
> > 3) This solution is to actually fix the runtime loader.  If an error
> >occurs with loading a shared library, then iterate over the entries
> >in the hints file to check to see if another hint would satisfy
> >the linking.  Here, instead of issuing the above error, the loader
> >would find entry 716, and load the correct libgcc_s.so.1.

This breaks if the bad libgcc is already linked. We'd have to rip
out the original bindings at run time, then re-bind to a new libgcc. 
I looked at the rtld code months ago. Nasty and silly.


> >
> >Admittedly, I haven't looked to see how difficult this solution
> >would be.


Very ;)

> >
> > 4) Bump the shared library number of the individual ports.  As a proof
> >of concept, I've done this with ports/lang/gcc6.
> >
...
> >
> > Finally, can people stop referring to the above error as
> > "gfortran's FreeBSD issue".  This is a FreeBSD runtime loader issue.

Yes, please. I tracked it down to libgcc months ago, made my findings
generally available and yet people are still calling it a libgfortran problem.

> >
> 
> Our libgcc also lacks some functionality compared to the original one:
> https://reviews.freebsd.org/D11482

Yes.


Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: new icestorm/arachne/yosys fpga toolchain port for cad/

[Diane Bruce]

On Wed, Jan 10, 2018 at 10:47:57AM -0500, Ash Gokhale wrote:
> I've ported  Cliford Wolf's/ Cotton Seed's amazing
> icestorm/yosys/arachne-pnr  open source toolchain for the lattice fpga
> bitstream generation, verilog translation, place and route engine  and
> supporting synthesis tools.
> 
> It works for me (tm) to the point of actually programming hadware. I would
> appreciate feedback or inclusion into the ports tree.
> https://github.com/agokhale/freebsd-port-arachne-pnr
> https://github.com/agokhale/freebsd-port-yosys
> https://github.com/agokhale/freebsd-port-icestorm

I'll take this on and give Ash a hand with these ports after
I catch up with things. We need more porters.

> ___
> 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"

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Linrad

[Diane Bruce]

On Sun, Nov 19, 2017 at 02:27:03AM +0100, Leif Asbrink wrote:
> Hello,
> 
> As the author of Linrad I would appreciate feedback from
> anyone who can suggest improvements. Presumably most - if not
> all - changes that have been done for FreeBSD could be 
> implemented in the Linrad package.

Hi Leif, I've worked with you before on improving linrad in the past
and I'd be happy to send you what diffs had to be made to linrad to
compile on FreeBSD. I suspect since we've been moving to team approach
for hamradio ports (hamradio@) sending these diffs upstream got overlooked.

I'll send you some updates via your email.


> Regards
> 
> Leif
> 
> Begin forwarded message:

73 Diane VA3DB
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Confirm: About freebsd Registration

[Diane Bruce]

On Wed, Oct 18, 2017 at 05:06:14PM -0400, scratch65...@att.net wrote:
> I've forwarded this to the FreeBSD Foundation at
> i...@freebsdfoundation.org for their action.  

http://www.techrepublic.com/blog/it-security/the-chinese-domain-scam/

> 
> I would guess that Runbang Holdings should not be granted the
> freebsd.*.cn domain names, since they probably have little or no
> connection to the FreeBSD Foundation and its work.  I might be
> wrong about that, of course, but the Foundation staff are the
> ones to sort it out in any case.
> 
> 
> [Default] On Thu, 19 Oct 2017 00:21:04 +0800, "Tony Liu"
>  wrote:
> 
> >Dear Manager,
> >(Please forward this to your CEO, because this is urgent. Thanks)
> >This is Tony Liu, Senior Manager of a Network Service Company which is the 
> >domain name registration center in Shanghai, China. On October 16th, 2017, 
> >we received an application from Runbang Holdings Ltd requested ??freebsd?? 
> >as their internet keyword and China (CN) domain names( freebsd.cn/ 
> >freebsd.com.cn/ freebsd.net.cn/ freebsd.org.cn).  But after checking it, we 
> >find this name conflict with your company name or trademark. In order to 
> >deal with this matter better, it??s necessary to send email to you and 
> >confirm whether this company is your distributor or business partner in 
> >China?
> >Best Regards
> >Tony Liu
> >Senior Manager
> >
> >
> >China Registrar Headquarters
> >www.chinaregistrar.org
> >8008, Tianan Building, No. 1399 Jinqiao Road, 
> >Shanghai 200120, China
> >0086-21-6191-8696(Tel) 
> >0086-1377-4400-340( Mobi)
> >0086-21-6191-8697(Fax)
> >___
> >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"
> ___
> 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"

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Using blaslapack

[Diane Bruce]

On Mon, Oct 16, 2017 at 07:19:49AM -0700, Steve Kargl wrote:
> On Mon, Oct 16, 2017 at 02:18:01AM -0700, Yuri wrote:
> > On 10/15/17 23:20, Gleb Popov wrote:
> > > I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there 
> > > is
...
> > Fortran implementation based on gcc is faulty due to libgcc_s.so being 
> > present in 2 versions, in base and in gcc port, making any code 
> > containing both C++ and fortran impossible to run. Your application 
> > probably can't work on FreeBSD using gcc fortran for this reason.
> > 
> 
> Huh?  I use Netlib blas/lapack compiled with gfortran on FreeBSD
> with no problem.  If you're having problems with gfortran finding
> the right libgcc_s.so, then add -rpath /usr/local/lib/gcc5 (or gcc6
> or gcc7) to yout Fortran options.

Steve is correct IFF it's a simple program, but wrong if it is a module.
What has been biting us are interpreters (e.g. python) not linked
against gfortran with the right -rpath but linked against our native libgcc.
When a binary module is loaded bad things happen if module was built
with fortran. If it is known beforehand that such modules will be loaded then
the work around is to LD_PRELOAD the gfortran libgcc or use 
LD_LIBRARY_PATH to force the gfortran libgcc to be loaded first instead
of ours. The problem is figuring out which programs load such binary
modules in the first place. There are a myriad of proper fixes possible
including bringing our libgcc up to spec.

Incidentally, flang compiled modules are one possible fix but is limited
to amd64 at the moment. Do not mix gfortran and flang
compiled modules in one program if they use I/O. Of course they use
their own I/O routines. *sigh*

> Steve

Diane (looking for that pony still)
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: manpath change for ports ?

[Diane Bruce]

On Tue, Mar 07, 2017 at 06:29:19AM +, Jan Beich wrote:
> Baptiste Daroussin  writes:
> 
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with at 
> > first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we need to 
> > patch
> >   upstream build system to install in a non usual path.
> 
> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
> try to encroach on GNU defaults.

A big yes from me for both of these proposals. 

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Problems with out libgcc_s.so in base

[Diane Bruce]

On Sun, Aug 21, 2016 at 03:37:58PM +0930, Shane Ambler wrote:
> On 20/08/2016 21:30, Diane Bruce wrote:
> > On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> >> On 19/08/2016 10:13, Steven G. Kargl wrote:
> > ...
> >> You should find that all newer copies of libgcc_s contain compatibility
> >> support for binaries that were linked to earlier versions.
> >>
> >
...
> 
> Actually the problem is going the other way. A port gets compiled and
> linked against the newer libs but at run time it finds the base system


*sigh* No.

> lib first and loads that which doesn't support the binary that is being
> run. If the gcc6 libgcc_s was always installed and found first then we
> wouldn't have this problem.

That's exactly what the -Wl,rpath=/usr/local/lib/lib is supposed to
do. 

Look at 
/usr/ports/Mk/Uses/gfortran.mk

FFLAGS+=-Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+=   -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin  

Any use of GCC to compile a port *SHOULD* have the same -rpath
otherwise it gets linked with our base libgcc_s which is *harmless*
99% of the time. The cases where it isn't are outlined here:
https://people.freebsd.org/~db/libgcc.txt

Your problem is cmake here.

>From blender Makefile

USES=   cmake:outsource compiler:features desktop-file-utils \
jpeg python:3.5 shebangfix

Look at this PR
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=20812

What happens is cmake strips the necessary rpath when it installs
the final binary.

This hack:
add to CMAKE_ARGS 
-DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"

Will tell cmake to not strip the necessary gcc rpath information.
BTW I'd be interested if this fixed blender for you.

However, if this is the way to fix these problems, then it should
be documented or fixed cmake. However a naive non ports infrastructure build
using gcc/gfortran or cmake will still run into these problems.

> 
> I first found this issue trying to import numpy into blender. As blender
> had started and was using the base libgcc_s, when I tried to import
> numpy that needed the newer libgcc_s for it's fortran code it failed. I
> discovered that setting LD_LIBRARY_PATH in the environment when starting
> blender got it to load the newer libgcc_s which then worked when

Yes. Or a LD_PRELOAD (man rtld)

The stanza added in the ports infrastructure is a kludge added to
work around our out of date base libgcc_s.so


> importing numpy, so I've been happy doing that for a couple of years.

This is exactly the sort of bugs that have been reported in the ports
system for years.

> 
> I have seen the same thing were a python module has brought in the base
> libgcc_s before numpy which needed the newer one. The dynamic loading of
> python modules seems to be the only time I have seen this. Either
> changing the import order or LD_LIBRARY_PATH to get the newer lib loaded
> the first time has solved the issue.

Yep. You are SOL if your base program does not have a -rpath linking
/usr/local/lib libgcc_s first. (BTW A LD_PRELOAD will fix your
problem here as it forces the port libgcc_s to be already loaded
before rtld has to search for it. It will satisfy the linking requirements
without messing around with LD_LIBRARY_PATH) Any program that does
a dlopen then requiring a ports libgcc_s will also fail, not just
python.

> 
> So one solution could be to copy the newer libgcc_s into /lib but the
> newer library won't get added to base as it contains GPLv3 code. Maybe 
> remove /lib/libgcc_s.so to force the search for a newer version.

If you read my original post. (Did you read it?) That's exactly what
I suggest. We should rename it to libcc_s.so 

...
> -- 
> FreeBSD - the place to B...Software Developing
> 
> Shane Ambler
> 
> 

Diane Bruce (Getting tired and testy at explaining this bug 1000 times)
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Problems with out libgcc_s.so in base

[Diane Bruce]

On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote:
> On 19/08/2016 10:13, Steven G. Kargl wrote:
...
> You should find that all newer copies of libgcc_s contain compatibility
> support for binaries that were linked to earlier versions.
> 

Indeed. And the version masquerading as a GNU libgcc_s in base
does the same thing. Two problems: our base libgcc_s only covers version up
to GCC_4.2.0 and there is a name conflict on the library name with
libgcc_s from the gnu compiler. Hence if a program links against base
libgcc_s first then requires libgfortran which itself requires support
for above GCC_4.2.0, the program fails. OR Whenever a program requires
support that is missing on the platform it is running on from our
libgcc_s, it will fail. 

There are numerous PR's on this which all have the common problem
of linking with a libgcc_s that does not support > GCC_4.2.0

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Problems with out libgcc_s.so in base

[Diane Bruce]

On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote:
> On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> > > 
> > > For example, on one of my systems, I now have these:
> > > 

> entry: 5
>   d_tag: DT_RPATH
>   d_val: /usr/local/lib/gcc6
> 
> I don't know how ELF or the ldd work, but shouldn't the DT_RPATH
> tell ldd to look for all of the above libraries in /usr/local/lib/gcc6
> first.  If a library isn't present, it would then look in ldconfig's
> hints file or fallback to /lib and /usr/lib/.  But, I suppose we 
> still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1
> from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps
> libcxxrt.so.1?).


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 

Anything compiled with cmake infrastructure loses the DT_RPATH.

> -- 
> Steve
> ___
> freebsd-toolch...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Problems with out libgcc_s.so in base

[Diane Bruce]

On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote:
> On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
> > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
> > > 
> > > Freebsd-ports could also use a wrapper:
> > > % cat ~/bin/gfc7
> > > #! /bin/sh
> > > DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'`
> > > export DIR
> > > 
> > > LD_LIBRARY_PATH=$DIR/work/7/lib
> > > export LD_LIBRARY_PATH
> > > 
> > > LD_RUN_PATH=$DIR/work/7/lib
> > > export LD_RUN_PATH
> > > 
> > > $DIR/work/7/bin/gfortran -fno-backtrace $@
> > 
> > Yes. I have also suggested we use a wrapper to the ports guys.
> > 
> 
> I thought about this a bit, and cleaner solution might be
> to add the program suffix to libgcc_s.so.1.  For example,
> 
> % cat foo.f90
> program foo
>print *, 'Hello'
> end program
> % gfortran6 -o z foo.f90 && ./z
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \
> /usr/local/lib/gcc6/libgfortran.so.3 not found
> % ldconfig -r | grep libgcc
> 6:-lgcc_s.1 => /lib/libgcc_s.so.1
> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
> 
> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
> be convinced to build, install, and use libgcc_s6.so.1, then the
> problem is solved without a wrapper.

I like this solution. 

> 
> -- 
> Steve
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Problems with out libgcc_s.so in base

[Diane Bruce]

On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
> 
> > The reason ports gcc now has this requirment on 4.6 or better is
> > fortran standard says we have to support quad floating point math.
> > e.g. /usr/local/lib/gccXX/libquadmath.so 
> 
> Diane,
> 
> Can you please stop with the dis-information?  No Fortran standard

I'm happy to be corrected. In this case it's immaterial if it is a
Fortran standard or not. It is what our present gcc from ports has given us.

...

> 
> FreeBSD-ports could avoid libquadmath issues by building gcc
> without it.  See --without-libquadmath or --without-quadmath (I
> don't remember the config option because it would be questionable
> to neuter one of gfortran's strength).

Correct. This blog entry I read some months ago outlines this
exact problem we are having and suggests the identical solution.

http://glennklockwood.blogspot.ca/2014/02/linux-perf-libquadmath-and-gfortrans.html

quadmath does have an impact on performance.


> 
> Freebsd-ports could also use a wrapper:
> % cat ~/bin/gfc7
> #! /bin/sh
> DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'`
> export DIR
> 
> LD_LIBRARY_PATH=$DIR/work/7/lib
> export LD_LIBRARY_PATH
> 
> LD_RUN_PATH=$DIR/work/7/lib
> export LD_RUN_PATH
> 
> $DIR/work/7/bin/gfortran -fno-backtrace $@

Yes. I have also suggested we use a wrapper to the ports guys.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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"

Problems with our libgcc_s.so in base

[Diane Bruce]

Problems with libgcc_s.so in base

If you compile with gcc and use our base libgcc it should DTRT
*provided* our libgcc has defined functions that are up to date
with current libgcc
We compile with gcc, it needs foo() from libgcc to run
doesn't matter what foo() is (A typical function would be T __multi3)

So our libgcc provides a foo() and gcc is happy 

This means in theory, we can interchangeably use gcc and clang in ports.
This also means it made the initial port work from from gcc in base
to clang in base a lot easier.

The problems come when we try to use architectures not fully
supported by our libgcc_s.so or when we use fortran.

However, our libgcc lies in two ways
1) our libgcc is mostly not GPL code anymore, though there are
   bits and pieces of GPL depending on what we don't have.

  This includes (or did) some of the work ian@ was trying to do with arm,
  various bits that arm libgcc provides from gcc were missing.

2) It claims to be only up to date with GCC 4.2.4

  Everything is peachy keen until someone references a symbol which is in
  anything gcc compiled using a newer > GCC 4.2.4 compiler.

The moment you load libgfortran, it has a requirement for GCC_4.6 or better,
and if our libgcc is already loaded things fail.

The reason ports gcc now has this requirment on 4.6 or better is
fortran standard says we have to support quad floating point math.
e.g. /usr/local/lib/gccXX/libquadmath.so 

We *could* lie in our libgcc_s and claim to be 4.6 which would simply
mean libgfortran would not complain and simply load the missing libquadmath.

If we updated the claimed GCC version in our libgcc_s.so to claim
GCC_4.6, we really also should provide a libquadmath subsitute.

The other approach is to rename our libgcc_s.so to libclang_s.so or
some such and link base with it instead of libgcc_s.so 

I frankly think this in the long term is the cleaner solution.

In the ports world, we have papered over this problem by adding
-Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link
against /usr/local/lib/gcc${GCCVERSION}/libgcc_s.so
However, any program that uses python to build has to be patched
to force this stanza and our ports cmake presently does not force 
this stanza to be added.  

Diane 
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: Poudriere testport failure but manual jailed build success

[Diane Bruce]

On Tue, Mar 03, 2015 at 05:24:15PM -0800, Chris H wrote:
> On Tue, 3 Mar 2015 23:37:30 +0100 Marin Bernard  wrote
> 
> > Hi,
> >  
> > I've been banging my head for several days on what follows and I've come to
> > the point where I have to get some help. Here's the point.  
> >
> > I'm trying to port LizardFS (a distributed file system for Unix/Linux) on
> > FreeBSD and I built a port candidate I would like to submit. But first I
> > needed to be sure everything was OK, so I ran some tests. As of now:
> >   - The port builds fine on FreeBSD 10.1-RELEASE amd64 host.
> >   - portlint does not report any issue (on the same host as above)
> >   - port test (from porttools) happily validates the port (on the same host
> > as above)   - BUT poudriere fails to build the port.
> >  
> > I'm using poudriere 3.1.1 on FreeBSD 11-Current, and failure occurs within a
> > FreeBSD 10.1-RELEASE amd64 jail.  
> >
> > What basically happens is that the build process runs fine until it reaches
> > man page generation. There, a2x throws an error because xlstproc returns 
> > with
> > return code 5 (= "error in the stylesheet"), whereas it shouldn't. What 
> > kills
> > me here is that if I enter the jail after the failure and try to build the
> > port manually, everything builds fine! You'll find poudriere log at the end
> > of this message.  
> >
> Any reason you couldn't simply lower the risk of failure based
> on tools you have no control over; by simply creating a valid
> man page to begin with? In other words; if the man is already
> properly formatted groff/troff/mandoc (take your pick). You
> wouldn't ever need to worry again. :)
> 
> Just a thought, and hope it helps.

I just ran into this one. Here is the fix. (months late)

You need a LIBDEPENDS on libxslt.so:textproc/libxslt

This probably should be documented in the porters handbook.


> 
> --Chris
> ..
> >

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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"

cmake and rpath problems

[Diane Bruce]

This is a heads up about a bug some of you have run into
and I've reported here.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120

To summarize: any binary or .so object linked using cmake will indeed
have a DT_RPATH entry, but it gets stripped out on install.

I worked around this with comms/sdr-wspr
by stripping the Fortran Flags to determine the RPATH and setting it
manually in CMakeLists.txt

+# temporary ugly hack
+string(REGEX MATCH "-rpath=.*" CMAKE_RPATH_ARG ${CMAKE_Fortran_FLAGS} )
+string(SUBSTRING ${CMAKE_RPATH_ARG} 7 -1 CMAKE_RPATH)
+set(CMAKE_INSTALL_RPATH ${CMAKE_RPATH} )

I know other ports have run into this.

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: USES=fortran can't mix with the libraries requiring /lib/libgcc_s.so.1 from the base

[Diane Bruce]

On Wed, Dec 23, 2015 at 04:35:29AM -0800, Yuri wrote:
> I found that ports with USES=fortran can't mix with anything in C++ 
> compiled with the base clang++, because USES=fortran forces the current 
> gcc that links with its /usr/local/lib/libgcc_s.so.1

It's a well known bug. The long term fix would be bringing in
quad math support which is what (gcc) fortran libs are looking for and
we do not supply currently.

Start here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196491
I tried very hard to make gnuradio compiled only with clang for the 'C'
parts but we were forced to use gcc.

> Getting this particular error from the python process, because one 
> python module has USES=fortran, and another has C++ in it:
> ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found

Yep.

> 
> What is the general solution for this problem? Is there a non-gcc 
> version of fortran?

No there is currently no clang version of Fortran. 'flang' was a SOC project
to bring in clang support for fortran but it is moribund. The
clang guys are the ones you should bug. In any case, the Fortran spec
now requires quad math support so that would have to be provided as well.

> 
> One thing is when gcc is required because clang can't compile something, 
> and another things is when fortran language requires it. The latter is 
> here to stay.
> 
> Can there be the separate fortran from gcc that is build with clang? Or 
> can we switch /usr/ports/lang/gccNN to be always built with the base 
> clang? I know this is certainly possible.

No. The core problem is due to our version of libgcc not having quadmath
support. 

> 
> Yuri

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: USES=fortran can't mix with the libraries requiring /lib/libgcc_s.so.1 from the base

[Diane Bruce]

On Wed, Dec 23, 2015 at 07:38:47AM -0800, Yuri wrote:
> On 12/23/2015 06:34, Diane Bruce wrote:
> > No. The core problem is due to our version of libgcc not having quadmath
> > support.
> >
> 
> If the separate port would have been created for gcc with only fortran 
> in it, and it would have been compiled with clang, this would have 
> solved this problem.

It is not that simple. Please read the various threads to understand why.

> 
> Yuri
> 

Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: gfortran (was: Any chances to reduce number of gcc ports/packages which are installed as BINARY PACKAGES dependencies?)

[Diane Bruce]

It looks good to me. 

On Mon, Nov 23, 2015 at 01:16:38AM +0100, Gerald Pfeifer wrote:
> On Tue, 22 Jul 2014, Diane Bruce wrote:
> > Any chance we could have a script "gfortran" which by default
> > ran the default gcc from bsd.default-versions.mk and make.conf ?
> 
> I know this took a little, ahem, but what do you think about
> the patch below?
> 
> With this change, lang/gcc, our canonical GCC port, now features
> gfortran as well as gcc and g++ without the appended major version 
> number.
> 
> (Not committed yet; feedback very welcome.)
> 
> Gerald
> 
> Index: Makefile
> ===
> --- Makefile  (revision 402204)
> +++ Makefile  (working copy)
> @@ -3,6 +3,7 @@
>  
>  PORTNAME=gcc
>  PORTVERSION= 4.8.5
> +PORTREVISION=1
>  CATEGORIES=  lang java
>  MASTER_SITES=GCC/releases/gcc-${DISTVERSION}
>  
> @@ -158,5 +159,10 @@
>   fi
>  .endfor
>   cd ${WRKDIR} ; ${SED} -i -e "/PLIST.lib/ r PLIST.lib" ${TMPPLIST}
> + # This is the canonical GCC port, so add key commands without
> + # version numbers as part of their names.
> + for c in gfortran g++ gcc; do \
> + ${LN} -s ${PREFIX}/bin/$$c${SUFFIX} ${STAGEDIR}${PREFIX}/bin/$$c; \
> + done
>  
>  .include 
> Index: pkg-plist
> ===
> --- pkg-plist (revision 402204)
> +++ pkg-plist (working copy)
> @@ -8,12 +8,15 @@
>  bin/%%GNU_HOST%%-gfortran%%SUFFIX%%
>  bin/c++%%SUFFIX%%
>  bin/cpp%%SUFFIX%%
> +bin/g++
>  bin/g++%%SUFFIX%%
> +bin/gcc
>  bin/gcc%%SUFFIX%%
>  bin/gcc-ar%%SUFFIX%%
>  bin/gcc-nm%%SUFFIX%%
>  bin/gcc-ranlib%%SUFFIX%%
>  bin/gcov%%SUFFIX%%
> +bin/gfortran
>  bin/gfortran%%SUFFIX%%
>  @comment info/gcc%%SUFFIX%%/dir
>  man/man1/cpp%%SUFFIX%%.1.gz
> 

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: all those c++ ABI variations in ports

[Diane Bruce]

The problem is now known. 
It's a lack of quad math support in our libcompiler_rt.
gfortran requires quad math support which our clang compiler does not
support yet, since Fortran itself needs quad math by the standard.
Normally this is never a problem if rpath is used and the local/lib
libgcc is used, but it does become a problem if a core program is
used which loads a module compiled with gfortran. The module loaded
expects quad math and will fail against our version of libgcc. Actually
it will fail in rtld.c code complaining that our version of libgcc
is not compatible with the version the gfortran code was compiled
against.



On Mon, Apr 27, 2015 at 12:56:36PM -0700, Don Lewis wrote:
 On 27 Apr, Diane Bruce wrote:
  A problem I have not seen noted here are ports that load run time modules.
  
  gnuradio is a case in point. The dependancies are all built (by default)
  with stock clang++  system libs but some of the runtime code it loads
  for operation has modules compiled with gfortran. 
 
 That should be a valid combination.  Fortran is part of ports gcc, but
 code compiled with it doesn't link to libstdc++, so there should not be
 a conflict with code compiled with clang++ and linked to libc++.  I
 haven't run into any issues with octave built with openblas, which is
 the combo that you describe.
 
 % ldd /usr/local/bin/octave
 /usr/local/bin/octave:
   libX11.so.6 = /usr/local/lib/libX11.so.6 (0x800823000)
   libutil.so.9 = /lib/libutil.so.9 (0x800b5c000)
   libm.so.5 = /lib/libm.so.5 (0x800d6e000)
   libc++.so.1 = /usr/lib/libc++.so.1 (0x800f96000)
   libcxxrt.so.1 = /lib/libcxxrt.so.1 (0x801255000)
   libgcc_s.so.1 = /usr/local/lib/gcc48/libgcc_s.so.1 (0x801471000)
   libthr.so.3 = /lib/libthr.so.3 (0x801687000)
   libc.so.7 = /lib/libc.so.7 (0x8018ab000)
   libxcb.so.1 = /usr/local/lib/libxcb.so.1 (0x801c57000)
   librpcsvc.so.5 = /usr/lib/librpcsvc.so.5 (0x801e76000)
   libXau.so.6 = /usr/local/lib/libXau.so.6 (0x80207f000)
   libpthread-stubs.so.0 = /usr/local/lib/libpthread-stubs.so.0 
 (0x802281000)
   libXdmcp.so.6 = /usr/local/lib/libXdmcp.so.6 (0x802482000)
 
 
 % ldd /usr/local/lib/octave/3.8.2/liboctave.so 
 /usr/local/lib/octave/3.8.2/liboctave.so:
   libcurl.so.4 = /usr/local/lib/libcurl.so.4 (0x802341000)
   libumfpack.so.1 = /usr/local/lib/libumfpack.so.1 (0x8025aa000)
   libsuitesparseconfig.so.1 = /usr/local/lib/libsuitesparseconfig.so.1 
 (0x802858000)
   libcholmod.so.1 = /usr/local/lib/libcholmod.so.1 (0x802a59000)
   libamd.so.1 = /usr/local/lib/libamd.so.1 (0x802d43000)
   libcamd.so.1 = /usr/local/lib/libcamd.so.1 (0x802f4a000)
   libcolamd.so.1 = /usr/local/lib/libcolamd.so.1 (0x803152000)
   libccolamd.so.1 = /usr/local/lib/libccolamd.so.1 (0x803359000)
   libcxsparse.so.1 = /usr/local/lib/libcxsparse.so.1 (0x803564000)
   libarpack.so.1 = /usr/local/lib/libarpack.so.1 (0x80378f000)
   libqrupdate.so.1 = /usr/local/lib/libqrupdate.so.1 (0x803a27000)
   libfftw3_threads.so.3 = /usr/local/lib/libfftw3_threads.so.3 
 (0x803c3d000)
   libfftw3.so.3 = /usr/local/lib/libfftw3.so.3 (0x803e43000)
   libfftw3f_threads.so.3 = /usr/local/lib/libfftw3f_threads.so.3 
 (0x8041a8000)
   libfftw3f.so.3 = /usr/local/lib/libfftw3f.so.3 (0x8043ae000)
   libopenblasp.so = /usr/local/lib/libopenblasp.so (0x80480)
   libreadline.so.8 = /lib/libreadline.so.8 (0x806576000)
   libncurses.so.8 = /lib/libncurses.so.8 (0x8067b9000)
   libpcre.so.1 = /usr/local/lib/libpcre.so.1 (0x806a06000)
   libgfortran.so.3 = /usr/local/lib/gcc48/libgfortran.so.3 (0x806c79000)
   libquadmath.so.0 = /usr/local/lib/gcc48/libquadmath.so.0 (0x806f9)
   libutil.so.9 = /lib/libutil.so.9 (0x8071cb000)
   libc++.so.1 = /usr/lib/libc++.so.1 (0x8073dd000)
   libcxxrt.so.1 = /lib/libcxxrt.so.1 (0x80769c000)
   libm.so.5 = /lib/libm.so.5 (0x8078b8000)
   libthr.so.3 = /lib/libthr.so.3 (0x807ae)
   libc.so.7 = /lib/libc.so.7 (0x800821000)
   libgcc_s.so.1 = /usr/local/lib/gcc48/libgcc_s.so.1 (0x807d04000)
   libssl.so.7 = /usr/lib/libssl.so.7 (0x807f1a000)
   libheimntlm.so.11 = /usr/lib/libheimntlm.so.11 (0x808186000)
   libhx509.so.11 = /usr/lib/libhx509.so.11 (0x80838c000)
   libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x8085d6000)
   libcrypto.so.7 = /lib/libcrypto.so.7 (0x8087d8000)
   libasn1.so.11 = /usr/lib/libasn1.so.11 (0x808bce000)
   libwind.so.11 = /usr/lib/libwind.so.11 (0x808e6b000)
   libheimbase.so.11 = /usr/lib/libheimbase.so.11 (0x809093000)
   libroken.so.11 = /usr/lib/libroken.so.11 (0x809297000)
   libcrypt.so.5 = /lib/libcrypt.so.5 (0x8094a9000)
   libz.so.6 = /lib/libz.so.6 (0x8096c9000)
   libkrb5.so.11 = /usr/lib/libkrb5.so.11 (0x8098df000)
   libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x809b57000)
   libgssapi_krb5.so.10 = /usr/lib/libgssapi_krb5.so.10 (0x809d6

Re: all those c++ ABI variations in ports

[Diane Bruce]

A problem I have not seen noted here are ports that load run time modules.

gnuradio is a case in point. The dependancies are all built (by default)
with stock clang++  system libs but some of the runtime code it loads
for operation has modules compiled with gfortran. 


-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: py-imaging vs. py-pillow

[Diane Bruce]

On Fri, Oct 03, 2014 at 02:01:32PM +0200, Stefan Ehmann wrote:
 On 03.10.2014 13:37, William Grzybowski wrote:
  Coexist how? They are essentially the same package. I don't see how
  thats possible.
 
 I meant that you should be able to install ports that depend on 
 py-imaging and ports that depend on py-imaging at the same time.
 
  py-imaging is deprecated, they should be switched to py-pillow and thats it.
 
 If py-pillow is a compatible drop-in replacement of py-imaging then 
 that's probably the best solution.

There is also the small matter of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193958

I don't know how many ports rely upon _imagingtk.so being installed
other than the ones I am blocked on. I need py-pillow since
my ports use python3.

I just noticed there is also another conflict that needs a PR filed.

pkg-static: py27-imaging-1.1.7_3 conflicts with py33-pillow-2.5.1 (installs 
files into the same place).  Problematic file: /usr/local/bin/pilconvert.py
*** [fake-pkg] Error code 70


- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Any chances to reduce number of gcc ports/packages which are installed as BINARY PACKAGES dependencies?

[Diane Bruce]

On Mon, Jul 21, 2014 at 11:32:11PM +0200, Gerald Pfeifer wrote:
 On Thu, 17 Jul 2014, Lev Serebryakov wrote:
   Maybe, we should encourage ports, which is needed gcc, to use only one
   version? If many ports needs 4.8, maybe, we should bump any version to
   4.8 for gcc-less systems? And move all other versions to 4.8?
 
 I would love to do that, in fact, I hope that at one point we can
 eventually get rid of USE_GCC=any.
 
 What I can do for now, and have been planning to do for a few weeks,
 is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192025 aka
 Update default version of GCC (USE_GCC=yes, lang/gcc,...) to GCC 4.8.

Any chance we could have a script gfortran which by default
ran the default gcc from bsd.default-versions.mk and make.conf ?

..
 
 Gerald
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Drop Maintainership, need help

[Diane Bruce]

On Thu, Jun 12, 2014 at 10:23:34PM +0200, Dennis Herrmann wrote:
 Ahoi,
 

libdsp would fit in nicely with hamradio@ team I think. I'll grab it.

 
 Thanks
 
 Regards,
 Dennis 'dhn' Herrmann
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: FreeBSD can now receive DAB(+) radio (and stereo wideband FM)

[Diane Bruce]

On Mon, Apr 29, 2013 at 12:50:41AM +0400, Lev Serebryakov wrote:
 Hello, Juergen.
 You wrote 28  2013 ??., 22:58:31:
 
 JL http://www.freshports.org/comms/dabstick-radio
 JL  Homepage:
 JL http://www.sdr-j.tk/
  Cool! And what about support for DVB-T sticks with Realtek chipset,
  which could be used as wideband SDR?

martymac and I have been working on that. gnuradio 3.6.3 will
shortly be in ports and when martymac is back from vaction, we will
have gr-osmosdr / gqrx ports.

  
 -- 
 // Black Lion AKA Lev Serebryakov l...@freebsd.org
 
 ___
 freebsd-multime...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia
 To unsubscribe, send any mail to freebsd-multimedia-unsubscr...@freebsd.org

- Diane (VA3DB)
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkg info list sources?

[Diane Bruce]

On Wed, Apr 17, 2013 at 11:23:35PM -0700, Beeblebrox wrote:
 I want a list of all installed packages in the form category/port. I will
 feed the list to poudriere.
 $ pkg info -ao  pkg.list
 gives a list but needs cleaning - gcc-4.6.3: lang/gcc
 How can I remove the left part of the colon and keep the trailing bit?

pkg info -ao |cut -f 2 -d ' ' -

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Fwd: Problem with svn properties on non-ascii file

[Diane Bruce]

On Sat, Mar 23, 2013 at 05:22:54PM +0400, Ruslan Makhmatkhanov wrote:
 
 
  Original message 
 Subject: Problem with svn properties on non-ascii file
 Date: Sat, 23 Mar 2013 17:20:55 +0400
 From: Ruslan Makhmatkhanov cvs-...@yandex.ru
 To: FreeBSD Developers develop...@freebsd.org
 
 Hi,
 
 I'm trying to commit update to deskutils/gourmet, that have this patch file:
 https://github.com/thinkle/gourmet/commit/9ad4df6f1387df10d3bd79752cfb6fbf0c285fa4
 
 I got this error both with using psvn and manually setting the
 properties (svn propset svn:mime-type text/plain
 patch-gourmet__defaults__defaults_ru.py):

That mime-type is clearly wrong if it is a binary file

http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.mime-type

If you are using psvn it forces a mime type of text which is wrong in this case.
 ${SVN} -q propset svn:mime-type text/plain ${_file}

You'll have to manually make sure this file has the right properties
and commit with svn not psvn.


 
 
 svn-commit.3.tmp 20L, 883C 
 SendingMakefile
 Sendingdistinfo
 Adding files
 Adding files/patch-gourmet__defaults__defaults_ru.py
 Sendingpkg-descr
 Sendingpkg-plist
 Transmitting file data .svn: E165001: Commit failed (details follow):
 svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
 Path
 head/deskutils/gourmet/files/patch-gourmet__defaults__defaults_ru.py
 contains binary but has svn:mime-type text/plain
 Try application/* (application/octet-stream) or image/* instead.
 == Pre-commit problem count: 1
 
 svn: E165001: Your commit message was left in a temporary file:
 svn: E165001:'/home/rm/learn/free/004/deskutils/svn-commit.3.tmp'
 
 
 I believe that the problem is because of utf-8 in patch file. So it's me
 who should fix something, or there is a problem with the hook itself?
 Thanks.
 
 -- 
 Regards,
 Ruslan
 
 Tinderboxing kills... the drives.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: rtld or lang/gcc cannot find libgcc_s.so.1

[Diane Bruce]

On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
 On 2012-02-21 20:42, Steve Kargl wrote:
 ...
  Yes, /lib comes before /usr/local/lib/gcc46.  I suppose
  that this is a heads up for gerald@. lang/gcc is used by
  the ports collections to build a large number of other
  ports, so others are likely to hit this issue.

Does -rpath not help ?

man ld
  -rpath dir
   Add a directory to the runtime library search path.  This  is  used
   when  linking  an  ELF  executable with shared objects.  All -rpath
   arguments are concatenated and passed to the runtime linker,  which
   uses  them  to locate shared objects at runtime.  The -rpath option
   is also used when locating  shared  objects  which  are  needed  by
   shared objects explicitly included in the link; see the description
   of the -rpath-link option.  If -rpath is not used when  linking  an
   ELF   executable,   the   contents   of  the  environment  variable
   LD_RUN_PATH will be used if it is defined.

Or is this another problem? -rpath is added in /usr/ports/Mk

 However, at runtime, it links against the system libstdc++:

I ran into this with two of my own ports. -rpath needed to be passed to ld.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [ANNOUNCE]: clang compiling ports, take 2

[Diane Bruce]

On Mon, Jul 25, 2011 at 05:59:20PM +0200, Roman Divacky wrote:
 Hi!
   
   
 Flz@ just run another exp-build with CC=clang and CXX=clang++. The results 
 can be
 seen here:
   
   
 http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/
 

It would be good to also do an exp run on i386. I ran into one port
that compiled fine with clang on amd64, but failed under i386.
(inline asm error)

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: 2nd deprecation campaign

[Diane Bruce]

On Thu, Jun 16, 2011 at 05:05:31PM +0200, Baptiste Daroussin wrote:
 2011/6/16 Baptiste Daroussin b...@freebsd.org:
  Hi all,
 
...
  Do not hesitate to manifest and undeprecate ports that would have
  deprecated by mistake. Even better do not hesitate to propose yourself
  to maintain them.

I've posted on the bsd-ham[1] list to see if anyone is using sattrack.
I do note an earlier version is available on amsat.org.
Other BSD users are on bsd-ham, so we'll see.

[1]
BSD-Ham mailing list
Home: http://mailman.qth.net/mailman/listinfo/bsd-ham  

- Diane db@
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: patch for force fetch

[Diane Bruce]

On Mon, May 16, 2011 at 10:02:57AM +0300, Andriy Gapon wrote:
 
 I've noticed the following problem.
 If a distfile is updated by a distributor without renaming it (so that 
 checksum
 and possibly size change), then more often than not the port build system 
 would
 fail to fetch the distfile.

I've run into this myself and simply done the manual rm -f. This looks like
a great addition.


-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: patch for force fetch

[Diane Bruce]

On Mon, May 16, 2011 at 10:22:23PM +0300, Andriy Gapon wrote:
 on 16/05/2011 19:53 Eitan Adler said the following:
  I've run into this myself and simply done the manual rm -f. This looks like
  a great addition.
  
  what about make distclean  ?
 
 Can you please elaborate?
 If you mean that I could just run 'make distclean', then my answer is why 
 should
 I.  I.e. if the ports infrastructure already knows that there is something 
 wrong
 with a local copy of a distfile (wrong size, wrong checksum), then it should
 just do the right thing and not annoy me to run some cleanup action.


I agree. Moreover, I've been thinking about the fetch operation in 
ports for a while, discussed with linimon@ once. There should be a way
to have a little more intelligence in that. e.g. if we are expecting
a binary tarball and we get back a html file, we know something has gone
wrong.

One of these years.

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Dropping maintainership of my ports

[Diane Bruce]

On Wed, Apr 27, 2011 at 07:35:58AM -0400, Jerry wrote:
 On Wed, 27 Apr 2011 09:49:58 +0200
 Erik Trulsson ertr1...@student.uu.se articulated:
 
  On Wed, Apr 27, 2011 at 12:15:43AM -0700, Charlie Kester wrote:
   On Tue 26 Apr 2011 at 23:27:40 PDT John Marino wrote:
   
...
   
   Every response from the committers ignored what I said I was trying
   to do, and instead repeated the same old arguments about stale,
   unfetchable, broken or superceded ports.  That talking points

No, no and no. If you have a copy of the upstream package the port was
based upon and it is open source, you can 'fork' it. Create a project
on sourceforge, or Berlioz, or somewhere, put the package there, announce it
get some people together to maintain it. That has the advantage of having
FreeBSD minded people maintaing it upstream. That's all. Easy Peasy.
That's for unfetchable ports or even superceded ports. If you prefer
an older program than a supposed newer suggested replacement, you can
fork the older program. That's how it works.

  (Actually the policy is that unmaintained and non-working ports should
  be let to die, unless somebody steps up to fix the port and take
  maintainership.)

Exactly. 

  
  Nobody is stopping you from assuming maintainership of one or more of
  those unmaintained ports, and thus preventing them from being removed.
 
 I concur with Erik. I think you are totally missing the point of the
 original post. The desired wish was to remove dead ports that could not
 be fetched, or would not build. Possibly, even superseded ports;

Right.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: saving a few ports from death

[Diane Bruce]

On Wed, Apr 27, 2011 at 08:02:34AM -0700, Chip Camden wrote:
 Quoth Eric on Wednesday, 27 April 2011:
...
   My search for popularity metrics is intended to point me, as a
   maintainer, to ports I might want to adopt now, rather than wait for
   someone to complain about them.  Everything *I* use is already
   maintained, so I've moved on to looking for things other people might
   need.  But I don't want to waste my time on something that nobody uses.
   :)

I have suggested in the past that part of the ports infrastructure could
toggle a count somewhere each time a port is made. This should be opt in 
of course. It would make it very easy to see which port might need a
maintainer.

- Diane 
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
  Why leave money to our children if we don't leave them the Earth?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6

[Diane Bruce]

On Fri, Jan 07, 2011 at 02:46:29PM -0600, Tom Judge wrote:
 On 01/07/2011 02:04 PM, Doug Barton wrote:
  On 01/07/2011 11:57, Olli Hauer wrote:
  
...
 
 Maybe we need a more generic way of doing this rather than each port
 providing their own implementation?

I like that idea. 

I was for a while running two openvpn instances, it was a right pita modifying
one.

*t_j* i.e. '/etc/rc.d/openvpn restart link1' will restart the process for
+/etc/openvpn/link1.conf
*t_j* it was discussed in #bsdports briefly

*agreed* that would be nice.

 
 Tom
 
 This is my slightly biased opinion as I am the author of one such script
 in the tree.

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Multiple subdirectories/sub-builds

[Diane Bruce]

On Wed, Oct 27, 2010 at 11:44:54AM -0500, Jim Riggs wrote:
 I am working on a new port that has several sub-builds.  That is, the 
 distfile has several subdirectories, each with its own 
 configure/make/install.  Are there any best practices or suggestions for 
 dealing with this scenario?  I didn't find anything in the handbook, and list 
 searches didn't turn up anything (though I don't know what exactly to search 
 for).

I have in the past simply created my own Makefile that descends into each
subdir and builds them. Stick it into files. Look at comms/trustedqsl

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Responding to a challenge

[Diane Bruce]

On Tue, Apr 20, 2010 at 03:05:22PM -0400, Thomas Abthorpe wrote:
...
  How about you two sing a duet at BSDCAN?
  
  - Diane
 
 Sadly my band is trapped in Europe, and I am personally unable to travel at
 this time, and will not be at BSDCan this year :(

Pity! I was going to suggest it would be worth a buck a piece for
developers to witness you singing, all proceeds to the FreeBSD foundation. ;-)

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Responding to a challenge

[Diane Bruce]

On Sun, Apr 18, 2010 at 11:52:43PM -0400, Thomas Abthorpe wrote:
 edwin@ threw down this gauntlet when I accepted my recent hat,
 http://blogs.freebsdish.org/tabthorpe/2010/03/25/catching-up-on-recent-events/comment-page-1/#comment-13022
 
 I have responded.  Sure it is lame, I am a porter, not a song writer!

Don't give up your day job.

 -- 
 Thomas Abthorpe   | FreeBSD Committer
 tabtho...@freebsd.org | http://people.freebsd.org/~tabthorpe


- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [Patch] Proposal: USE_GNU89 switch

[Diane Bruce]

Hi,

On Sat, May 30, 2009 at 04:34:43PM +0200, Ed Schouten wrote:
 * Gabor Kovesdan ga...@freebsd.org wrote:
  As for LLVM, probably it won't work out for the whole ports
  tree. I don't know what's the portmgr opinion on this, if we start to
  use LLVM in Ports Collection, we should reconsider the knob, though.

As the plan is to have both gcc + clang in -9 we are still going to
run into this problem. I would expect a lot of users are going to
just expect ports to work with clang as well as gcc.

 LLVM/Clang support is trivial. Erwin Lansing fired up an experimental
 ports build for us and the numbers are *very* promising. There are still
 some issues with the compiler itself, but so far it seems the only
 architectural change to the tree that needs to be made, is a hint to
 fall back to C89.

By the time FreeBSD-9 is released clang support will be solid and all ports
will compile with clang as well as gcc. Clang was chosen because of their
committment to have full gcc compatibility.


 This is not just about LLVM/Clang support. If the GCC folks ever decide
 to switch to C99 by default, we'll have exactly the same issue.

Agreed.

I don't see the harm in trying Ed_'s diff on a exp. run with both gcc
and clang and compare a gcc run with a stock run. Perhaps this is something
Itetcu could help with.

- Diane
--
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Problems building ports - Error code 2 when attempting to cd

[Diane Bruce]

On Wed, Nov 05, 2008 at 09:04:18PM -0500, Scott Ullrich wrote:
...
 Anything else you can think to check?

Look for this variable set somewhere. ALWAYS_BUILD_DEPENDS

 ===   rrdtool-1.2.26_1 depends on shared library: freetype.9 - found
(but building it anyway)

This message but building it anyway is odd. looking in /usr/ports/Mk ,
I'd like to know why ALWAYS_BUILD_DEPENDS is set.
That can't be right. What are you typing to do the make?

--
- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Port: libxml2-2.6.31

[Diane Bruce]

On Sat, May 10, 2008 at 04:23:59PM -0500, Jeremy Messenger wrote:
 On Sat, 10 May 2008 16:12:46 -0500, Fabien Debuire [EMAIL PROTECTED]
 wrote:

 Hello there is a mismatch with the checksum for this port since you
 change
 mirrors order can you please update this

 I have tested on all mirrors before I have committed this change. I still
 can't reproduce it here.

This is probably one of the bugs that stalks the ports system.
It is possible you got a html text message saying the server was too
busy stored into libxml2-2.6.31.tar.gz; the ports system at present does
not use file to check that the file it has fetched matches what it
was expecting. This is one of the cases where manual intervention is
necessary and you have to remove the file downloaded and try again.

It's not that easy a bug to fix unfortunately.

- Diane
--
- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Port: fldigi-2.10

[Diane Bruce]

On Tue, Apr 22, 2008 at 11:26:45AM -0700, Chris Maness wrote:

Resolved.

It never occured to me Chris was missing a soundcard. This is the
assert trap from portaudio2. ;-) It's a very cryptic message.

- Diane (VA3DB)
--
- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Port: fldigi-2.10

[Diane Bruce]

On Tue, Apr 22, 2008 at 10:33:37AM -0700, Chris Maness wrote:

 Here is what I got after rebuilding.

...
 Hamlib version 1.2.6.1
 PortAudio V19-devel 1899
 libsndfile-1.0.17
 Abort trap: 6 (core dumped)

At this point, it sounds like a hardware problem. Check your RAM.

- 73 Diane VA3DB
--
- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Port: comms/acfax

[Diane Bruce]

On Mon, Apr 21, 2008 at 07:41:07PM -0400, Roland Burgan wrote:
 What is considered the best Satellite Tracking program  predictor, in
 real time, for Ubuntu?

Why not run http://www.pcbsd.org instead and just install the PBI
for gpredict or predict? It is a lot easier.

- 73 Diane VA3DB (amsat coordinator)
--
- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Port: fldigi-2.10

[Diane Bruce]

On Mon, Apr 21, 2008 at 06:39:46PM -0700, Chris Maness wrote:
 Hello, Diane,

 I am having trouble getting fldigi to compile.  Also, the binary install
 core dumps (signal 11) on two different FreeBSD installs.  This is on
 release 7.0.

hrmmm ugh fldigi-2.10 runs fine here on i386 FreeBSD 7.0. What architecture
are you on? Does it happen to be amd64? I'll need to see a gdb bt if you
can.


 /usr/bin/ld: cannot find -lgio-2.0
 gmake: *** [libgiofam.la] Error 1
 *** Error code 2

 Stop in /usr/ports/devel/gio-fam-backend.
 *** Error code 1

This problem is actually in devel/gio-fam-backend

I have duplicated the problem.

/usr/bin/ld: cannot find -lgio-2.0
gmake: *** [libgiofam.la] Error 1
*** Error code 2

But I am not sure how this could happen. Are your ports up to date?

Basically gio-fam-backend has a dependancy on /usr/ports/devel/glib20
or should have. Unless glib20 port is installed first, libgiofam will fail.
I've only taken a quick cursory look, but it appears this might be
related to a commit to /usr/ports/Mk/bsd.gnome.mk

# $FreeBSD: ports/Mk/bsd.gnome.mk,v 1.146 2008/03/24 15:59:55 marcus Exp $

In the meantime, cd /usr/ports/devel/glib20;make install
then return to your fldigi build.

 Also, I have been able to get tlf working in console using screen.  You
 might have already known this, but I just found out about it a couple of
 weeks ago.  Maybe put a small notice about screen for vt100
 compatibility in the install script.  I had sent you an e-mail regarding
 the terminal issues a while back, but I guess that would be a good fix.
 The only issue I have found is that backspace still does not work under
 FreeBSD.

Yes, I remember your comment about that. I'll look at it again, thanks.

- 73 Diane VA3DB
--
- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: BSD stats project: what about packages?

[Diane Bruce]

On Tue, Sep 05, 2006 at 07:45:06PM +, Alexey Dokuchaev wrote:
 On Tue, Sep 05, 2006 at 02:22:45PM -0500, Mark Linimon wrote:
  On Tue, Sep 05, 2006 at 12:53:03PM -0400, michael johnson wrote:
...
 OK is when such ports find their way into release CDs, while others
 (like SDL) do not.

Unless you are building a specialised hamradio CD ;-)



--
- [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: opera on -current

[Diane Bruce]

Hi,

So that everyone else knows.

Finally tracked it down after linking it through libmap
against libthr.

0x29110fba pthread_setcancelstate+14: add$0x277b,%ebx
0x29110fc0 pthread_setcancelstate+20: mov0xc(%ebp),%ecx
0x29110fc3 pthread_setcancelstate+23: mov%gs:0x8,%edx
0x29110fca pthread_setcancelstate+30: test   %ecx,%ecx
0x29110fcc pthread_setcancelstate+32: mov0x5c(%edx),%eax

ecx0x291b401d   689651741
edx0x0  0
ebx0x29113734   688994100

edx is 0. I'm told this is TLS (Thread local storage) which is
known to be broken on -current.

I remember TLS being reported as broken on -current, it had honestly slipped
my mind.

So opera out of the box on -current will not work.

People who have opera working on -current are either using linux-opera
or a compat library.

I'm not sure if it is worth while marking the port broken for -current
now or not, but I figure there should be some note of it being broken
for current somewhere.

--
- [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

opera on -current

[Diane Bruce]

Hi,

Anyone using the opera port successfully on -current?

--
- [EMAIL PROTECTED] http://www.db.net/~db
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]