It's a bit of a crazy way...
qt5-webengine has python27 in BUILD_DEPENDS, but not in RUN_DEPENDS.
Prepare such a package by downloading it from somewhere.
# If you want to download it from the official, the URL should be as follows,
but I can't find it directly right now :)
# And this is the pack
On Sat, 10 Apr 2021 00:34:46 +0200
Christoph Moench-Tegeder wrote:
> ## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org):
>
> > portmaster -d cad/freecad
>
> That installs all the build dependencies (and the build dependencies
> of the dependencies, etc.) in your syste
## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org):
> portmaster -d cad/freecad
That installs all the build dependencies (and the build dependencies
of the dependencies, etc.) in your system - and that includes the old
python 2.7 as a build dependency of qt5-webkit (which itself is
requi
On Fri, 9 Apr 2021 07:17:18 +0900
Tatsuki Makino wrote:
> LuMiWa via freebsd-ports wrote on 2021/04/07 06:46:
> > I didn't install because it pull Python 2.7. I didn't change any
> > configuration. FreeCAD has just collada but other I left default. QT
> > Web eng
LuMiWa via freebsd-ports wrote on 2021/04/07 06:46:
> I didn't install because it pull Python 2.7. I didn't change any
> configuration. FreeCAD has just collada but other I left default. QT
> Web engine pulls Gstreamer and I thing something from Gstreamer pulls
> Python 2.
not do, but what you did
> do. How did you try to install FreeCAD?
>
> Regards,
> Christoph
>
portmaster -d cad/freecad
--
“We live in a world where there is more and more information, and less
and less meaning.”
Jean Baudrillard
___
## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org):
> I didn't install because it pull Python 2.7. I didn't change any
> configuration.
The question is not so much what you did not do, but what you did
do. How did you try to install FreeCAD?
Regards,
Christoph
On Tue, 6 Apr 2021 22:14:21 +0200
Christoph Moench-Tegeder wrote:
> ## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org):
>
> > I try to install cad/freecad and it pulls lang/Python 27.
>
> FreeCAD itself depends on Python "3.6 or higher". What exactly did
> y
## LuMiWa via freebsd-ports (freebsd-ports@freebsd.org):
> I try to install cad/freecad and it pulls lang/Python 27.
FreeCAD itself depends on Python "3.6 or higher". What exactly did
you do?
> I didn't install.
So you're sying it's not relevant anymore anyway?
Hi!
I try to install cad/freecad and it pulls lang/Python 27. I thought
that we are done with version 27. I didn't install.
Thank you.
--
“We live in a world where there is more and more information, and less
and less meaning.”
Jean Baudri
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?
>
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!
--
Regar
## 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_m5a7
ked up as expected).
> > As a possible workaround I forced "-L/usr/local/lib" into LDFLAGS -
> > looks like the linker invocation should now work in your case.
> >
>
> updated the ports tree again, and tried upgrading the FreeCAD port,
> but the build fails as before
ges?)
>
> Anyways, I gave up on this (there are too many variables and I
> still cannot reproduce this in clean environments, whatever I do
> Coin is picked up as expected).
> As a possible workaround I forced "-L/usr/local/lib" into LDFLAGS -
> looks like the linker invocation
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
## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
> BTW, bellow are library dependencies and one of them is libmed.so which
> is part of french/med which pull aster:
french/med uses the same distfile as french/aster, but it does not
depend on the port french/aster, neither at build nor at r
On Sun, 24 Feb 2019 22:12:21 +0100
Christoph Moench-Tegeder wrote:
> ## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
>
> > Subject: freecad cannot build
>
> Oh, it can, e.g.:
> http://beefy6.nyi.freebsd.org/data/120amd64-default/493629/logs/FreeCAD-0.17.13541_6.log
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
## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
> Subject: freecad cannot build
Oh, it can, e.g.:
http://beefy6.nyi.freebsd.org/data/120amd64-default/493629/logs/FreeCAD-0.17.13541_6.log
and my local build logs look very similar.
> All ports are built on FreeBSD-Release-12-p3
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
All ports are built on FreeBSD-Release-12-p3 (amd64). I did install
package for french/med because french/aster doesn't build on amd64. But
on the end of building freecad I got:
/usr/bin/ld: error: unable to find library -lCoin
/usr/bin/ld: error: unable to find library -lGL
/usr/bin/ld:
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
lution
# https://wiki.freebsd.org/libgcc%20problem
export LD_PRELOAD=/usr/local/lib/gcc8/libgcc_s.so
FreeCAD $*
No libgcc_s.so.1 problems over three consecutive test all runs.
'FreeCAD' is a binary executable that runs a lot of python under the
hood. That&#x
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
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 Te
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
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
LD_LIBRARY_PATH /usr/local/lib/gcc8
setenv LD_RUN_PATH /usr/local/lib/gcc8
Steve,
script:
#! /bin/sh
export LD_LIBRARY_PATH=/usr/local/lib/gcc8
export LD_RUN_PATH=/usr/local/lib/gcc8
FreeCAD $*
And now the errors are different with no /lib/libgcc_s.so.1 error, but
if I rerun the tests in the GUI
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
self?
Regards,
Christoph
--
___
CMakeLists.txt exists in /src/GUI/ directories :
https://github.com/FreeCAD/FreeCAD/blob/releases/FreeCAD-0-17/src/Gui/CMakeLists.txt
( Coin is referenced )
https://github.com/FreeCAD/FreeCAD/tree/releases/FreeCAD-0-17/src/Gui/Qua
yed.
> Perhaps you can do some digging by yourself?
>
> Regards,
> Christoph
>
> --
> _______
>
CMakeLists.txt exists in /src/GUI/ directories :
https://github.com/FreeCAD/FreeCAD/blob/releases/FreeCAD-0-17/src/Gui/CMakeLists.txt
( Coin is referenced )
https://gi
## 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
/plugins/tts/flite]
> > Project ERROR: Unknown module(s) in QT: multimedia *** Error code
> > 3
>
> 1. that's qt5-speech, not FreeCAD
> 2. looks like a typical case of local contamination: the error happens
>in the flite plugin. The flite plugin is not build by
> Reading
> /usr/ports/accessibility/qt5-speech/work/qtspeech-everywhere-src-5.12.1/src/plugins/tts/flite/flite.pro
> [/usr/ports/accessibility/qt5-speech/work/.build/src/plugins/tts/flite]
> Project ERROR: Unknown module(s) in QT: multimedia *** Error code 3
1. that's qt5
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/
1 - 100 of 132 matches
Mail list logo
