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

[Tijl Coosemans]

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

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

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

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

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

I can only recommend that you try the patches.  Your Fortran/Python
pipeline will just work like it does on Linux.  I've attached them once
more for your convenience.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldconfig.patch
Type: text/x-patch
Size: 3761 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20190222/846a9ec2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfortran8.patch
Type: text/x-patch
Size: 2017 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20190222/846a9ec2/attachment-0001.bin>