gcc - building libarchive

[Andi B.]

I try to build *nix library libarchive and get the following error about unresolved '_pthread_mutex_unlock'.

Code: [Select]

....
  CC       libarchive/archive_write_set_passphrase.lo
  CC       libarchive/filter_fork_posix.lo
  CC       libarchive/xxhash.lo
  CCLD     libarchive.la
./libtool: 2643: ./libtool: func__fatal_error: not found
weakld: error: Unresolved symbol (UNDEF) '_pthread_mutex_unlock'.
weakld: info: The symbol is referenced by:
    P:\dev\ports\libarchive-3.3.3\libarchive\.libs\archive_random.o
weakld: error: Unresolved symbol (UNDEF) '_pthread_mutex_lock'.
weakld: info: The symbol is referenced by:
    P:\dev\ports\libarchive-3.3.3\libarchive\.libs\archive_random.o
Ignoring unresolved externals reported from weak prelinker.
Error! E2028: _pthread_mutex_lock is an undefined reference
Error! E2028: _pthread_mutex_unlock is an undefined reference
file P:\dev\ports\libarchive-3.3.3\libarchive\.libs\archive_random.o(archive_random.o): undefined symbol _pthread_mutex_lock
file P:\dev\ports\libarchive-3.3.3\libarchive\.libs\archive_random.o(archive_random.o): undefined symbol _pthread_mutex_unlock
make.exe[1]: *** [libarchive.la] Error 1
make.exe[1]: Leaving directory `P:/dev/ports/libarchive-3.3.3'
make.exe: *** [all] Error 2
"P:\usr\lib\pthread.a" includes these functions. Seems this file isn't linked.

Any ideas?

[Dave Yeo]

Look in the configure.in script to see how pthreads is linked in. Just went through that with a different program that Lewis was building, in that case needed to add an OS/2 section with a special pthreads link line (-lpthread) and removing the -pthreads line.
BTW, doing make V=1 (or set V=1 first) will give a more informative output.

[jailbird]

It should be possible to edit the gcc specs file so that -pthreads automatically enables -lpthreads. That way you don't have to hack every app separately.

[Dave Yeo]

It should be possible to edit the gcc specs file so that -pthreads automatically enables -lpthreads. That way you don't have to hack every app separately.

Yeh, most of the time it just works currently but there's like 4 ways to invoke pthreads and the maintainers haven't fixed the specs. IIRC, -pthread works and -pthreads doesn't. Sometimes just adding libs=-lpthread or LDFLAGS=-lpthread is all that is needed and most of the time not even that. Having an OS/2 section in some configure scripts is also a good place to add other flags such as -Zomf

[Dave Yeo]

Built for me with make LDFLAGS=-lpthread V=1 haven't looked at configure closely though it looks like it just checks for pthread.h without actually linking it.

[Lars]

I was given this shell script to create the makefiles for a cmake based project (where the source is located in ..\git directory), to be called from the "build" directory:

export LDFLAGS='-Zhigh-mem -Zomf -lcx -lpthread'
export CFLAGS='-Zomf -O2 -g -march=pentium4 -Wno-attributes'

cmake  -DCMAKE_INSTALL_PREFIX:PATH=/@unixroot/usr \
    -DCMAKE_BUILD_TYPE:STRING=debug \
    ../git

Shouldn't that do the trick ? Might need to adjust the cmake defines for your case.

[Dave Yeo]

I was given this shell script to create the makefiles for a cmake based project (where the source is located in ..\git directory), to be called from the "build" directory:

export LDFLAGS='-Zhigh-mem -Zomf -lcx -lpthread'
export CFLAGS='-Zomf -O2 -g -march=pentium4 -Wno-attributes'

cmake  -DCMAKE_INSTALL_PREFIX:PATH=/@unixroot/usr \
    -DCMAKE_BUILD_TYPE:STRING=debug \
    ../git

Shouldn't that do the trick ? Might need to adjust the cmake defines for your case.

It had both cmake and auto tools building. I don't know cmake.
Your script is slightly broken depending. With CFLAGS=-Zomf, creating static libs will fail unless you also put into the environment AR=emxomfld and RANLIB=echo, not sure if cmake uses the environment for those and not everything builds static libs. Also -g should be both in CFLAGS and LDFLAGS as far as I know.
I've also been using -mtune=generic so it is not optimized for Pentium 4 but rather the common CPU's

[Andi B.]

Built for me with make LDFLAGS=-lpthread V=1 haven't looked at configure closely though it looks like it just checks for pthread.h without actually linking it.

Thanks that did the trick. Had to remove some other xxFLAGS I tried before and sh ./configure. But now it seems to work.

Next step, try to build iii-0.3 (libarchive is a requirement for that).

[Jochen Schäfer]

I looked at libarchive, too, but it needs support for OS/2 EAs.

[Dave Yeo]

Ideally would be an xttrs command/function, that way things like this would just work.

[Jochen Schäfer]

I looked into that. But the xattr interface doesn't fit to the way OS/2's EA work.

[Dave Yeo]

Seems just need a translation interface with OS/2 EA's being of type user, and ignoring ACL's for now.
Pretty sure if booted to Linux, a mounted JFS partition would allow xttrs to manipulate the OS/2 EA's. They're of key:value everywhere by the looks of it.
Might also want to filter out the libc stuff or put in system

[Jochen Schäfer]

The problem is: OS/2 zip ports just uses the memory layout of OS/2's EA api in the extension space (don't know the correct terminology) of a file stored in the zip. It also uses a OS/2 specific ID for it. Paul can correct me, if I got that wrong.
That means the XAttr stores the EA in a completely different layout as OS/2 zips do. You can go this route, but it seems to me, it will be completely incompatible to our established archiving programs.
BTW, I was beginning to write a xattr interface for libc, but the sheer amount of infrastructure needed to cope with OS/2 all in one place file oriented approach in a item oriented api, gave me headaches and made me drop it for the moment.
Also, there is the issue of different EA types, like icons etc. xattr only deals with memory blobs, it has no way to treat application defined EA, which might be essential for the functioning of an application, correctly without annotating the xattr attributes, which again will break compatibility.

If you want to do the xattr approach, go for it. I don't know, if it is worth it.
It seems to me far easier to copy the Windows approach and extend libarchive that way.