pkgbox status?

[Jeremy C. Reed]

On pkgbox, I am getting the following when attempting to compile code in
pkgsrc:

/usr/libexec/ld-elf.so.2: /usr/lib/libpthread.so.0: Undefined symbol
"__sys__exit"

The kernel is

DragonFly pkgbox.dragonflybsd.org 2.3.2-DEVELOPMENT DragonFly
v2.3.2.843.gfb78b3-DEVELOPMENT #181: Tue Sep  8 20:50:50 PDT 2009    
root@...:/build/usr.obj/usr/src/sys/PKGBOX  i386

lrwxr-xr-x  1 root  wheel      11 Aug 24 09:20 /usr/lib/libc_r.so -> libc_r.so.5
-r--r--r--  1 root  wheel  100964 Aug 24 09:20 /usr/lib/libc_r.so.5
lrwxr-xr-x  1 root  wheel       9 May  3  2007 /usr/lib/libpthread.so.0 -> libc_r.so
-r-xr-xr-x  1 root  wheel  165296 Aug 24 09:21 /usr/libexec/ld-elf.so.2

[Matthew Dillon]

:On pkgbox, I am getting the following when attempting to compile code in
:pkgsrc:
:
:/usr/libexec/ld-elf.so.2: /usr/lib/libpthread.so.0: Undefined symbol
:"__sys__exit"
:
:The kernel is
:
:DragonFly pkgbox.dragonflybsd.org 2.3.2-DEVELOPMENT DragonFly
:v2.3.2.843.gfb78b3-DEVELOPMENT #181: Tue Sep  8 20:50:50 PDT 2009    
:root@...:/build/usr.obj/usr/src/sys/PKGBOX  i386
:
:lrwxr-xr-x  1 root  wheel      11 Aug 24 09:20 /usr/lib/libc_r.so -> libc_r.so.5
:-r--r--r--  1 root  wheel  100964 Aug 24 09:20 /usr/lib/libc_r.so.5
:lrwxr-xr-x  1 root  wheel       9 May  3  2007 /usr/lib/libpthread.so.0 -> libc_r.so
:-r-xr-xr-x  1 root  wheel  165296 Aug 24 09:21 /usr/libexec/ld-elf.so.2

    pkgbox has been sitting idle for most of the month since we don't
    really do anything on it any more now that our 386 package building
    is being done elsewhere.  I was planning on merging its functionality
    with crater (but haven't yet).  Basically it just provides the /archive
    NFS export for leaf.

    I could throw on a new world & kernel and we can see where that leads.

                                        -Matt
                                        Matthew Dillon
                                        <dillon@...>

[Jeremy C. Reed]

On Wed, 16 Sep 2009, Matthew Dillon wrote:

>     pkgbox has been sitting idle for most of the month since we don't
>     really do anything on it any more now that our 386 package building
>     is being done elsewhere.  I was planning on merging its functionality
>     with crater (but haven't yet).  Basically it just provides the /archive
>     NFS export for leaf.

I use it sometimes to test some pkgsrc updates and builds. If crater can
be used to do pkgsrc builds instead that would be fine. Also okay to do
development work on it? Now I just saw I no longer have login to crater
(but my passphrase for my key is correct) -- appears to be for git use
only.

>     I could throw on a new world & kernel and we can see where that leads.

That would be nice. I only had a src tree checked out on pkgbox in my home
and I had noticed some minor bugs with pkg_search I was going to fix. I
will open a bug ticket for now.

[Matthew Dillon]

:I use it sometimes to test some pkgsrc updates and builds. If crater can
:be used to do pkgsrc builds instead that would be fine. Also okay to do
:development work on it? Now I just saw I no longer have login to crater
:(but my passphrase for my key is correct) -- appears to be for git use
:only.
:
:>     I could throw on a new world & kernel and we can see where that leads.
:
:That would be nice. I only had a src tree checked out on pkgbox in my home
:and I had noticed some minor bugs with pkg_search I was going to fix. I
:will open a bug ticket for now.

    Ok, it sounds like I should keep them as separate machines for now
    then.  Yah, crater mostly only allows git logins (for pushes).  Shell
    access is minimized as a security precaution.

    I will put a new kernel & world on pkgbox.  It will take about two
    hours.

    Maybe what I should do is move /archive off of pkgbox and onto crater
    so pkgbox is then only used for pkg builds and playing around.  Crater
    is an old machine...  its our last UP box in fact, but it doesn't
    actually need much cpu to handle git and /archive functions.

                                        -Matt
                                        Matthew Dillon
                                        <dillon@...>

[Justin C. Sherrill]

On Wed, September 16, 2009 8:46 pm, Matthew Dillon wrote:

>     Maybe what I should do is move /archive off of pkgbox and onto crater
>     so pkgbox is then only used for pkg builds and playing around.  Crater
>     is an old machine...  its our last UP box in fact, but it doesn't
>     actually need much cpu to handle git and /archive functions.

The only 'legacy' item left on pkgbox that I can think of is a redirect in
the Apache config that sends requests for binary packages back over to
avalon.  Even that doesn't really need to stick around much longer.

[Nicolas Thery]

2009/9/17 Jeremy C. Reed <reed@...>:
> On pkgbox, I am getting the following when attempting to compile code in
> pkgsrc:
>
> /usr/libexec/ld-elf.so.2: /usr/lib/libpthread.so.0: Undefined symbol
> "__sys__exit"

2009/9/17 Jeremy C. Reed <reed@...>:
> On pkgbox, I am getting the following when attempting to compile code in
> pkgsrc:
>
> /usr/libexec/ld-elf.so.2: /usr/lib/libpthread.so.0: Undefined symbol
> "__sys__exit"

I observed that too only when linking against libc_r.  I rebuilt world
several times but that did not help.  I was planning to reinstall the
system from scratch with 2.4 and investigate if the problem persists.

[Jeremy C. Reed]

On Thu, 17 Sep 2009, Nicolas Thery wrote:

> > /usr/libexec/ld-elf.so.2: /usr/lib/libpthread.so.0: Undefined symbol
> > "__sys__exit"
>
> I observed that too only when linking against libc_r.  I rebuilt world
> several times but that did not help.  I was planning to reinstall the
> system from scratch with 2.4 and investigate if the problem persists.

Now at  2.5.0-DEVELOPMENT DragonFly v2.5.0.2.gd351a-DEVELOPMENT #182:

Any ideas on how I can track this down?

When I build with gcc -pthread the problem continues.

[Steve O'Hara-Smith]

On Wed, 16 Sep 2009 18:21:37 -0500 (CDT)
"Jeremy C. Reed" <reed@...> wrote:

> On pkgbox, I am getting the following when attempting to compile code in
> pkgsrc:
>
> /usr/libexec/ld-elf.so.2: /usr/lib/libpthread.so.0: Undefined symbol
> "__sys__exit"
>
> The kernel is
>
> DragonFly pkgbox.dragonflybsd.org 2.3.2-DEVELOPMENT DragonFly
> v2.3.2.843.gfb78b3-DEVELOPMENT #181: Tue Sep  8 20:50:50 PDT 2009    
> root@...:/build/usr.obj/usr/src/sys/PKGBOX  i386
>
> lrwxr-xr-x  1 root  wheel      11 Aug 24 09:20 /usr/lib/libc_r.so ->
> libc_r.so.5 -r--r--r--  1 root  wheel  100964 Aug 24
> 09:20 /usr/lib/libc_r.so.5 lrwxr-xr-x  1 root  wheel       9 May  3
> 2007 /usr/lib/libpthread.so.0 -> libc_r.so -r-xr-xr-x  1 root  wheel
> 165296 Aug 24 09:21 /usr/libexec/ld-elf.so.2

        Coming late to the party here - but wouldn't these links be better
pointed to libthread_xu which has been standard for quite some time now.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

[Hasso Tepper-3]

Steve O'Hara-Smith wrote:
> Coming late to the party here - but wouldn't these links be better
> pointed to libthread_xu which has been standard for quite some time
> now.

Yes, libc_r is there for testing purpose only nowadays. But that's not the
excuse to be broken. Especially while taking account that we don't (maybe
we should?) adjust libpthread.so.0 symlink while upgrading.

Anyway, the problem with libc_r should be fixed now as well.


--
Hasso Tepper

[Steve O'Hara-Smith]

On Fri, 25 Sep 2009 10:28:52 +0300
Hasso Tepper <hasso@...> wrote:

> Steve O'Hara-Smith wrote:
> > Coming late to the party here - but wouldn't these links be better
> > pointed to libthread_xu which has been standard for quite some time
> > now.
>
> Yes, libc_r is there for testing purpose only nowadays. But that's not
> the excuse to be broken. Especially while taking account that we don't
> (maybe we should?) adjust libpthread.so.0 symlink while upgrading.

        I got caught a few weeks ago by coredumps in flwm and synergyc with
libc_r (the packages had been built on a box with libthread_xu and
installed on one that still had libc_r linked). I'd be happy to see the
links switched during upgrade.

> Anyway, the problem with libc_r should be fixed now as well.

        Is there really any point in keeping libc_r around anymore.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

[Jeremy C. Reed]

If I should be using libpthread_xu.so instead, what are the steps to
make Dragonfly and/or pkgsrc use it by default?

Any webpage or documentation about this?

(In other words, what are others doing to get around this problem? Or is
it just that the system I am using is inproperly installed or way out
of date, even though it has been upgraded many times?)

[Hasso Tepper-3]

Jeremy C. Reed wrote:
> If I should be using libpthread_xu.so instead, what are the steps to
> make Dragonfly and/or pkgsrc use it by default?
>
> Any webpage or documentation about this?
>
> (In other words, what are others doing to get around this problem? Or
> is it just that the system I am using is inproperly installed or way
> out of date, even though it has been upgraded many times?)

The system in general should be fine, just two symlinks need to be
adjusted:

cd /usr/lib
rm libpthread.a
ln -s libthread_xu.a libpthread.a
rm libpthread.so.0
ln -s libthread_xu.so libpthread.so.0


--
Hasso Tepper