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 system - and that includes
## 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
required
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 engine pulls Gstreamer and I thing so
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.7.
make -C /usr/ports/www
On Thu, 8 Apr 2021 20:09:12 +0200
Christoph Moench-Tegeder wrote:
> ## 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
## 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
--
Spare Space
_
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
> you do?
>
> > I didn't install.
## 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?
Regards,
Christoph
--
Spare S
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
## 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
> and my local build
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 (amd64).
H
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 found
> >
> > This is probably fatal to pract
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 particular
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
> thank very much all the porti
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
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...@kg-core
## 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
1 - 100 of 101 matches
Mail list logo
