On Mon, 8 Apr 2019, Tijl Coosemans wrote:
>> This patch make 3 the default for gfortran.
> s/make/makes/ but otherwise the patch looks fine.
Thank you, Tijl.
I updated lang/gcc8 (including bumping its PORTREVISION) and will
apply the same to lang/gcc8-devel next, and then lang/gcc9-devel
so lang/
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 bi
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-
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 F
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
Sorry for being late to the party, but this Differential revision looks
related: https://reviews.freebsd.org/D11482
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freeb
On Fri, 22 Mar 2019 23:54:14 +0100
Torfinn Ingolfsen wrote:
> Hello,
>
> On Mon, Mar 18, 2019 at 10:02 PM Christoph Moench-Tegeder
> wrote:
> > I didn't get around to analyse this very deeply - instead I upgraded
> > FreeCAD to 0.18 - does that change anything?
>
> FreeCAD 0.18 installed from
Hello,
On Mon, Mar 18, 2019 at 10:02 PM Christoph Moench-Tegeder
wrote:
> I didn't get around to analyse this very deeply - instead I upgraded
> FreeCAD to 0.18 - does that change anything?
FreeCAD 0.18 installed from ports without any problem.
Thank you!
--
Regards,
Torfinn
___
## Torfinn Ingolfsen (tin...@gmail.com):
> updated the ports tree again, and tried upgrading the FreeCAD port,
> but the build fails as before.
> I've put the build output and CMakeOutput.log (there is no
> CMakeError.log) at
> https://sites.google.com/site/tingox/asus_m5a78l_usb3_freebsd
> in cas
On Sat, 2 Mar 2019 16:55:16 +0100
Torfinn Ingolfsen wrote:
> On Sun, Feb 24, 2019 at 11:22 PM Christoph Moench-Tegeder
> wrote:
> >
> >
> > The main question is why it detects Coin as "-lCoin", which can't
> > be found by the linker without a matching "-L/usr/local/lib" (it's
> > ok when Coin is
On Sun, Feb 24, 2019 at 11:22 PM Christoph Moench-Tegeder
wrote:
>
>
> The main question is why it detects Coin as "-lCoin", which can't
> be found by the linker without a matching "-L/usr/local/lib" (it's
> ok when Coin is linked as just "/usr/local/lib/libCoin.so").
> There may be some hints in
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@!
And first of all, let me apologize. Clearly the experience both Tijl
as a contributor made, as well as the one some of our users inclu
On Mon, Feb 25, 2019 at 1:58 AM Dima Pasechnik
wrote:
>
> On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl
> wrote:
> >
> > On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote:
> > > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote:
> > > > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima
On Mon, Feb 25, 2019 at 01:58:01AM +, Dima Pasechnik wrote:
> On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl
>
> > Given that I actually don't
> > program in python, that certainly seems to be an unreasonable
> > request from the python maintainers.
>
> If I were a Python maintainer I might hav
On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl
wrote:
>
> On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote:
> > 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
## Torfinn Ingolfsen (tin...@gmail.com):
> I looked into the build log, but it doesn't tell me anything new:
> Coins is detected during configure / setup phase, and the suddenly
> during compile / link it fails a step because Coin (specifically
> -lCoin) can't be found
The main question is why it
On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote:
> 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,
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:
>
On Sat, Feb 23, 2019 at 6:31 PM Diane Bruce wrote:
[...]
> 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?
Diane,
well, after reading many threads on this issue I stumbled upon
https://forums.freebsd.org/t
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
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 ne
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 al
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 disc
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 alig
On Fri, Feb 22, 2019 at 10:27:30AM -0800, Steve Kargl wrote:
> Then the assertion that nothing in base needs libgcc_s.so is wrong?
>
> And, yes, if an application is currently using /lib/libgcc_s.so,
> then it would need to be recompiled. When it is recompiled, it
> can use libcompiler_rt or, if
On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote:
> >
> > 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 t
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.
On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
> 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 pro
On Fri, Feb 22, 2019 at 08:44:54AM -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
> > wrote:
> > > Yes, we absolutely must avoid situation where two similar libraries
> > > (i.e. providing some s
On Fri, Feb 22, 2019 at 05:11:20PM +0100, Tijl Coosemans wrote:
> On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl
>
> > 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
On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
> 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 pro
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 d
On 2/22/19 6:04 AM, Tijl Coosemans wrote:
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 maintaine
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
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. t
On Fri, Feb 22, 2019 at 12:28:41PM +0100, Tijl Coosemans wrote:
> > 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 l
On Fri, Feb 22, 2019 at 09:32:03AM -0500, Ed Maste wrote:
> On Thu, 21 Feb 2019 at 16:47, Steve Kargl
> wrote:
> >
> > The missing symbols are
> >
> > % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
>
> Thank you for collecting these.
>
> > It looks like we may be able
On Thu, 21 Feb 2019 at 16:47, Steve Kargl
wrote:
>
> The missing symbols are
>
> % objdump -x lib/libgfortran.so | grep GCC_4.6.0 | awk '{print $5}' | sort
Thank you for collecting these.
> It looks like we may be able to grab some of these from libc/softfloat:
> getf2.c, gttf2.c, letf2.c, lttf2
On Fri, Feb 22, 2019 at 02:04:07PM +0100, Tijl Coosemans wrote:
> 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. Ca
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
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 w
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 whatev
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
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 sh
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
>
Dia
On Thu, Feb 21, 2019 at 10:24:51AM -0800, Steve Kargl wrote:
>
> As anyone tried adding an empty sections to FreeBSD's
> libgcc_s,
>
> /*
> * Empty sections to work around FreeBSD abusing the name
> * of a well-known GCC library.
> */
> GCC_4.6.0 {
>
> } GCC_4.3.0;
>
> GCC_4.7.0 {
>
> } GCC
On Thu, Feb 21, 2019 at 10:53:00AM -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 interact
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.
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.
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
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
>
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.
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 foun
On 2/17/19 9:16 AM, Eugene Grosbein wrote:
17.02.2019 22:46, Diane Bruce wrote:
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
17.02.2019 22:46, Diane Bruce wrote:
>> 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/l
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
On Sat, Feb 16, 2019 at 12:23 PM Christoph Moench-Tegeder
wrote:
>
> ## Torfinn Ingolfsen (tin...@gmail.com):
>
> > root@kg-core1# cmake --find-package -DNAME=Coin3D -DCOMPILER_ID=clang
> > -DLANGUAGE=CXX -DMODE=LINK
> > -Wl,-rpath,/usr/local/lib /usr/local/lib/libCoin.so
>
> That looks completely
17.02.2019 22:41, Diane Bruce wrote:
>> 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
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 rp
17.02.2019 22:15, Diane Bruce wrote:
> 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 mod
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
...
>
## Russell L. Carter (rcar...@pinyon.org):
> I've been building on an 8 core system but am moving to a 32 core
> system today.
Hm, with great power comes great electricity bill? :)
Regards,
Christoph
--
Spare Space
___
freebsd-ports@freebsd.org maili
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
> > the first one it finds. If it fails, it fails. It
> > does not look to see
On Sun, Feb 17, 2019 at 01:13:15PM +0700, Eugene Grosbein wrote:
> 17.02.2019 12:56, Steve Kargl 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
> >>> the first one it finds. If
17.02.2019 12:56, 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
>>> the first one it finds. If it fails
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 rp
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
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?
>
Read the rtld manpage. You're hitting #5 in the list,
because the first 4 aren't satisified. Now, look at
'ldconfig -r | grep libgcc_s'.
--
On Sun, Feb 17, 2019 at 08:21:00AM +0700, Eugene Grosbein wrote:
>
> 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/libqua
17.02.2019 12:11, Steve Kargl wrot:
>> # 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
"Russell L. Carter" writes:
> /lib/libgcc_s.so.1 version GCC_4.8.0 required by
> /usr/local/lib/gcc8/libgfortran.so.5 not found
[...]
> Question to experienced porters, how is this best practice solved?
Try adding USES=fortran to freecad in order to propagate GCC LDFLAGS
as old libgcc_s.so maybe
17.02.2019 8:58, Russell L. Carter wrote:
> On 2/16/19 6:44 PM, Eugene Grosbein wrote:
>> 17.02.2019 8:35, Russell L. Carter wrote:
>>
> Transcribed output from the FreeCAD Testing Framework GUI test all:
>
> First run of TestApp.All: Run: 212 Failures: 1 Errors: 20
>
> which i
On 2/16/19 6:44 PM, Eugene Grosbein wrote:
17.02.2019 8:35, Russell L. Carter wrote:
Transcribed output from the FreeCAD Testing Framework GUI test all:
First run of TestApp.All: Run: 212 Failures: 1 Errors: 20
which isn't bad at all I suspect. However one of the failures is
/lib/libgcc_s.s
17.02.2019 8:35, Russell L. Carter wrote:
>>> Transcribed output from the FreeCAD Testing Framework GUI test all:
>>>
>>> First run of TestApp.All: Run: 212 Failures: 1 Errors: 20
>>>
>>> which isn't bad at all I suspect. However one of the failures is
>>>
>>> /lib/libgcc_s.so.1 version GCC_4.8.0
On 2/16/19 6:14 PM, Steve Kargl wrote:
On Sat, Feb 16, 2019 at 06:02:11PM -0700, Russell L. Carter wrote:
/lib/libgcc_s.so.1 version GCC_4.8.0 required by
/usr/local/lib/gcc8/libgfortran.so.5 not found
Question to experienced porters, how is this best practice solved?
setenv LD_LIBRARY_PAT
On 2/16/19 6:21 PM, Eugene Grosbein wrote:
17.02.2019 8:02, Russell L. Carter wrote:
Greetings,
Restarting the FreeCAD 0.17 discussion on a different tangent.
As I mentioned before I am building (for now) outside of the ports
tree FreeCAD-git + Coin-hg + QT5 + med-4.0.0. I want to
17.02.2019 8:02, Russell L. Carter wrote:
> Greetings,
>
> Restarting the FreeCAD 0.17 discussion on a different tangent.
>
> As I mentioned before I am building (for now) outside of the ports
> tree FreeCAD-git + Coin-hg + QT5 + med-4.0.0. I want to particularly
> th
On Sat, Feb 16, 2019 at 06:02:11PM -0700, Russell L. Carter wrote:
>
> /lib/libgcc_s.so.1 version GCC_4.8.0 required by
> /usr/local/lib/gcc8/libgfortran.so.5 not found
>
>
> Question to experienced porters, how is this best practice solved?
>
setenv LD_LIBRARY_PATH /usr/local/lib/gcc8
setenv
Greetings,
Restarting the FreeCAD 0.17 discussion on a different tangent.
As I mentioned before I am building (for now) outside of the ports
tree FreeCAD-git + Coin-hg + QT5 + med-4.0.0. I want to particularly
thank very much all the porting work that has been done so far, I
wouldn't have
On 2/16/19 9:14 AM, Mehmet Erol Sanliturk wrote:
On Sat, Feb 16, 2019 at 6:07 PM Christoph Moench-Tegeder
wrote:
## Torfinn Ingolfsen (tin...@gmail.com):
root@kg-core1# cmake --find-package -DNAME=Coin3D -DCOMPILER_ID=clang
-DLANGUAGE=CXX -DMODE=LINK
-Wl,-rpath,/usr/local/lib /usr/local/lib/
On Sat, Feb 16, 2019 at 6:07 PM Christoph Moench-Tegeder
wrote:
> ## Torfinn Ingolfsen (tin...@gmail.com):
>
> > root@kg-core1# cmake --find-package -DNAME=Coin3D -DCOMPILER_ID=clang
> > -DLANGUAGE=CXX -DMODE=LINK
> > -Wl,-rpath,/usr/local/lib /usr/local/lib/libCoin.so
>
> That looks completely r
## Torfinn Ingolfsen (tin...@gmail.com):
> root@kg-core1# cmake --find-package -DNAME=Coin3D -DCOMPILER_ID=clang
> -DLANGUAGE=CXX -DMODE=LINK
> -Wl,-rpath,/usr/local/lib /usr/local/lib/libCoin.so
That looks completely right. But the error message was
/usr/bin/ld: cannot find -lCoin
so something
## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
> Thank you but why FreeCAD need all this QT ports?
FreeCAD uses Qt for it's GUI (and a CAD system without GUI is
somewhat 1980ish). Formerly it used Qt4, but as that is going
away in four weeks, I switched it over to Qt5 - that's an option
On Fri, 15 Feb 2019 18:51:04 +0100
Christoph Moench-Tegeder wrote:
> ## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
>
> > Reading
> > /usr/ports/accessibility/qt5-speech/work/qtspeech-everywhere-src-5.12.1/src/plugins/tts/speechdispatcher/speechdispatcher.pro
> >
> > [/usr/ports/ac
## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
> Reading
> /usr/ports/accessibility/qt5-speech/work/qtspeech-everywhere-src-5.12.1/src/plugins/tts/speechdispatcher/speechdispatcher.pro
>
> [/usr/ports/accessibility/qt5-speech/work/.build/src/plugins/tts/speechdispatcher]
> Reading
I did try to build on my FreeBASD-Release 12.0 (amd 64) wit portmaster
and with default options and I stack:
Reading
/usr/ports/accessibility/qt5-speech/work/qtspeech-everywhere-src-5.12.1/src/plugins/tts/speechdispatcher/speechdispatcher.pro
[/usr/ports/accessibility/qt5-speech/work/.build/
On Thu, Feb 14, 2019 at 11:02 PM Christoph Moench-Tegeder
wrote:
>
> ## Torfinn Ingolfsen (tin...@gmail.com):
>
> > It fails here:
>
> Interesting.
>
> > /usr/bin/ld: cannot find -lCoin
>
> And that shouldn't happen - at least, it didn't happen here.
>
> > Is there anything more I can do / provide
## Christoph Moench-Tegeder (c...@burggraben.net):
> I'll try reproducing this once I've an idle CPU
I let it run over night, and there we are:
build started at Fri Feb 15 05:39:35 CET 2019
port directory: /usr/ports/cad/freecad
package name: FreeCAD-0.17.13541_6
building for: FreeBSD elch.exwg.
On Fri, Feb 15, 2019 at 12:26 AM Torfinn Ingolfsen wrote:
> On Sat, Feb 9, 2019 at 10:12 PM Christoph Moench-Tegeder
> wrote:
> >
> > There. Please test :)
> >
>
> It fails here:
>
> [ 27%] Linking CXX shared library ../../lib/libFreeCADGui.so
> cd /usr/ports/cad/freecad/work/.build/src/Gui && /
## Torfinn Ingolfsen (tin...@gmail.com):
> It fails here:
Interesting.
> /usr/bin/ld: cannot find -lCoin
And that shouldn't happen - at least, it didn't happen here.
> Is there anything more I can do / provide?
Your system is reasonable "standard"? You don't have a poudriere
environment aroun
On Sat, Feb 9, 2019 at 10:12 PM Christoph Moench-Tegeder
wrote:
>
> There. Please test :)
>
It fails here:
[ 27%] Linking CXX shared library ../../lib/libFreeCADGui.so
cd /usr/ports/cad/freecad/work/.build/src/Gui && /usr/local/bin/cmake
-E cmake_link_script CMakeFiles/FreeCADGui.dir/link.txt --
On 2/8/19 8:13 PM, Torfinn Ingolfsen wrote:
Just checking: is anyone using FreeCAD 0.17 (cad/freecad) under FreeBSD at all?
I installed it from ports, I'm running
tingo@kg-core1$ uname -a
FreeBSD kg-core1.kg4.no 11.2-STABLE FreeBSD 11.2-STABLE #0 r342545:
Thu Dec 27 00:29:46 CET 2018
r.
On Saturday, February 9, 2019 1:00:02 PM CET freebsd-ports-requ...@freebsd.org
wrote:
> From: Torfinn Ingolfsen
> To: FreeBSD Ports ML
> Subject: FreeCAD 0.17 - is anyone using it?
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
>
> Just
## Torfinn Ingolfsen (tin...@gmail.com):
> > working on moving it to Qt5, to avoid deprecation in 6 weeks.
> > It's not 100% complete yet, but at least the widgets are looking
> > much nicer now :) Expect an update "soonish".
There. Please test :)
Regards,
Christoph
--
Spare Space
On Sat, Feb 9, 2019 at 2:02 PM Christoph Moench-Tegeder
wrote:
>
>
> I'm not a heavy CAD user, but FreeCAD as such is working.
>
> I'm on 12.0-STABLE, but that shouldn't matter that much.
>
Thanks for the confirmation. I've also received confirmation from
someone using it with FreeBSD 11.2-stable
## Torfinn Ingolfsen (tin...@gmail.com):
> Just checking: is anyone using FreeCAD 0.17 (cad/freecad) under FreeBSD at
> all?
I'm not a heavy CAD user, but FreeCAD as such is working.
> I installed it from ports, I'm running
> tingo@kg-core1$ uname -a
> FreeBSD kg
Just checking: is anyone using FreeCAD 0.17 (cad/freecad) under FreeBSD at all?
I installed it from ports, I'm running
tingo@kg-core1$ uname -a
FreeBSD kg-core1.kg4.no 11.2-STABLE FreeBSD 11.2-STABLE #0 r342545:
Thu Dec 27 00:29:46 CET 2018
r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC
/426753/logs/FreeCAD-0.17.g20160907_1.log
mcl
___
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"
Hmm ...
I am not even the port maintainer anymore and I still get these error
messages.
FWIW, in the trunk version we just tagged it broken for 9.x.
Pedro.
Forwarded Message
Subject: [package - 93i386-quarterly][cad/freecad] Failed for
FreeCAD-0.17.g20160907_1 in build
99 matches
Mail list logo
