最新の lhaをビルドしようとすると、このエラーが表示されます。

/usr/local/bin/ld: header.o: in function `ConvertEncodingByIconv':
/usr/local/tmp/crew/6f6cbc1.tar.gz.dir/lha-6f6cbc189d23b7c3a8636819f5796654f188764e/src/header.c:2024: undefined reference to `libiconv_open'
/usr/local/bin/ld: /usr/local/tmp/crew/6f6cbc1.tar.gz.dir/lha-6f6cbc189d23b7c3a8636819f5796654f188764e/src/header.c:2030: undefined reference to `libiconv'
/usr/local/bin/ld: /usr/local/tmp/crew/6f6cbc1.tar.gz.dir/lha-6f6cbc189d23b7c3a8636819f5796654f188764e/src/header.c:2038: undefined reference to `libiconv_close'
/usr/local/bin/ld: /usr/local/tmp/crew/6f6cbc1.tar.gz.dir/lha-6f6cbc189d23b7c3a8636819f5796654f188764e/src/header.c:2032: undefined reference to `libiconv_close'
collect2: error: ld returned 1 exit status

これが機能するためには libiconvとリンクする必要があるようです。

これが紛らわしい場合は申し訳ありませんが、私は翻訳者を使用しています。

gcc (Debian 8.3.0-6) 8.3.0

gcc -DHAVE_CONFIG_H -I. -I..  -DEUC -DSUPPORT_LH7   -g -O2 -MT header.o -MD -MP -MF .deps/header.Tpo -c -o header.o header.c
header.c: In function '_skip_bytes':
header.c:71:1: warning: type of 'len' defaults to 'int' [-Wimplicit-int]
 _skip_bytes(len)
 ^~~~~~~~~~~

https://stackoverflow.com/a/18424897/1430535

Hello, I compiled on linux using ./configure CC=i686-w64-mingw32-gcc && make, I get a windows executable that seems to work, however when I try to create an archive with
lha a0 archive.lha file
I get this:
LHa: Fatal error: Cannot open file "/tmp/lhP1kAlM": No such file or directory
When compiled natively on linux it works properly.

Also, the binary here http://gnuwin32.sourceforge.net/packages/lha.htm works perfectly on windows, can you please tell me how you compiled it?
Thank you

前回のリリース (ac20050924p1, 2006-10-17) から長期間経過し、その間にバグ/セキュリティ修正や機能追加も行われており、一度区切りとしてリリースする時期に来ているのではないかと思います。

また、LHa for UNIX 1.15～1.17が長期間メンテナンスされていない現状、これらより新しいことを示すバージョン番号を付けた方が良いのではないかと思います。
(だいぶ昔にも話があったものの、そのまま立ち消えになっていたような…)

リリースに向けて課題となっている事はありますでしょうか?

Maybe 1.15?

Hi! I am packaging lha for pkgsrc (see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/archivers/lha ). I have a lot of Amiga .lha files around so lha is very useful to me.

The previous distribution file from http://www2m.biglobe.ne.jp/~dolphin/lha/lha-unix.htm is no longer available, so I found your version.

You have integrated almost all patches that pkgsrc had for lha-1.14i. There is one patch that might be good to have upstream. It replaces a call to utime() with utimes(), because utime() is listed as deprecated.

--- src/lhext.c.orig    2020-12-17 15:59:30.545844796 +0000
+++ src/lhext.c
@@ -220,13 +220,15 @@ adjust_info(name, hdr)
     char           *name;
     LzHeader       *hdr;
 {
-    struct utimbuf utimebuf;
+    struct timeval utimebuf[2];
 
     /* adjust file stamp */
-    utimebuf.actime = utimebuf.modtime = hdr->unix_last_modified_stamp;
+    utimebuf[0].tv_sec = hdr->unix_last_modified_stamp;
+    utimebuf[0].tv_usec = 0;
+    utimebuf[1] = utimebuf[0];
 
     if ((hdr->unix_mode & UNIX_FILE_TYPEMASK) != UNIX_FILE_SYMLINK)
-        utime(name, &utimebuf);
+        utimes(name, &utimebuf[0]);
 
     if (hdr->extend_type == EXTEND_UNIX
         || hdr->extend_type == EXTEND_OS68K

(packaging patches are usually not the best practice, but short and minimal; I noticed that there is some code to conditionally define struct utimbuf, which could be removed as well).

Further, I could no so easily find the version number. I had to look at configure.ac to find 1.14i-ac20081023. 2008-10-23 is a long time ago :-) When it is an appropriate moment, can you maybe create a release version, with a new version number (maybe 1.15)? That, with a nice tag, so that it appears in https://github.com/jca02266/lha/releases would be very nice.

Thanks for keeping lha updated!

I've had issues unpacking some Amiga archives because of iconv, I've posted a bug here you should look at.

Hello. I'm assisting with packaging LHA for Gentoo and found a few issues that I wanted to call to your attention. Best I can tell these are not Gentoo-specific, so I thought it'd make sense to get them patched upstream.

I'm including patch files for each. Please forgive the manual approach to this - I'm not especially familiar with git and unsure how to submit a pull request.

fix-config_headers.patch

This updates AM_CONFIG_HEADER, which was deprecated by automake, with AC_CONFIG_HEADERS. Reference here:
https://www.gnu.org/software/automake/manual/automake.html

fix-getopt_long-delaration.patch

This updates the include syntax to support current versions of GCC, which requires using quotes to search for include files relative to the current file. The <> syntax only searches system directories now. Reference here:
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

fix-file-list-from-stdin.patch

This re-enables support for specifying file lists via stdin, which was already present but disabled because it apparently doesn't work with mingw32. This patch detects whether mingw32 is being used and only then disables the code. No authoritative reference, but discussion here:
https://bugs.gentoo.org/184911

Please let me know if you need any additional info or I could assist further. Thanks!

解凍時のOverWrite ?(Yes/[No]/All/Skip)に対して^Dを入力すると無限ループします。

READMEには sh ./configure --disable-iconv とせよとありますが、漢字コードの変換が行われません。
sh ./configure --disable-iconv --enable-multibyte-filename=utf8 とするとうまくいきます。

I've tried to access http://lha.osdn.jp with a browser but it's not working. When in a browser, after a very long period of time the site will eventually return:

504 Gateway Time-out

I've repeated the steps in curl:

Leela ~ # curl -Lv 'http://lha.osdn.jp'
* Host lha.osdn.jp:80 was resolved.
* IPv6: (none)
* IPv4: 54.148.152.249, 52.32.250.235
*   Trying 54.148.152.249:80...
* connect to 54.148.152.249 port 80 from 192.168.88.2 port 55324 failed: Połączenie odrzucone
*   Trying 52.32.250.235:80...
* connect to 52.32.250.235 port 80 from 192.168.88.2 port 53636 failed: Przekroczony czas oczekiwania na połączenie
* Failed to connect to lha.osdn.jp port 80 after 134546 ms: Couldn't connect to server
* Closing connection
curl: (28) Failed to connect to lha.osdn.jp port 80 after 134546 ms: Couldn't connect to server

I've also portscanned the site to see if maybe I should be going to https instead, or if there is any quasi-secret port operating there:

Leela ~ # nmap -p 80,443,8080,8443 lha.osdn.jp -Pn
Starting Nmap 7.94 ( https://nmap.org ) at 2024-05-05 15:59 CEST
Nmap scan report for lha.osdn.jp (52.32.250.235)
Host is up.
Other addresses for lha.osdn.jp (not scanned): 54.148.152.249
rDNS record for 52.32.250.235: ec2-52-32-250-235.us-west-2.compute.amazonaws.com

PORT     STATE    SERVICE
80/tcp   filtered http
443/tcp  filtered https
8080/tcp filtered http-proxy
8443/tcp filtered https-alt

Nmap done: 1 IP address (1 host up) scanned in 3.24 seconds

It seems that this host's typical HTTP ports are firewalled from public view.

This lead me down the rabbithole of investigating with osdn.jp even is: https://en.wikipedia.org/wiki/OSDN
Alright so maybe the .jp TLD is outdated? Looks like it:

• https://osdn.net loads, but horribly slow
• https://ja.osdn.net also loads, but much faster

So it turns out there are 2 project pages for lha on OSDN:

1. https://ja.osdn.net/projects/lha I can barely understand what's going on here, but this GitHub project is mentioned there
2. https://osdn.net/projects/lha here it says the project moved to GitHub

Maybe with such turn of events, it would be appropriate to update the homepage of this GitHub project?

I have the Quake 1.06 CD and wanted to extract the gamedata from it on arm64 in order to make the case that games-fps/quake1-data package in Gentoo can receive an arm64 keyword, making the installation of this package less of a hack on this CPU architecture.

The extraction failed and I've started looking into when and how it failed. If we mount the CD into /mnt/cdrom, we can do lha l /mnt/cdrom/resource.1 to try and receive the file list in the archive, however, it fails:

PERMISSION  UID  GID      SIZE  RATIO     STAMP           NAME
---------- ----------- ------- ------ ------------ --------------------
LHa: Error: Checksum error (LHarc file?)
---------- ----------- ------- ------ ------------ --------------------
 Total         0 files       0 ****** Nov  5  1996

As a matter of curiosity I've repeated the procedure on amd64 and got the same result.

This issue is reproducible with these commits:

• 7c3cd95
• 2695022
• 4f193b1

I have a couple of old files from an Amiga, from 1994 and 1997 respectively, which get corrupted when I try to update them with LHa for Unix. They work OK with LHA 2.13 in DOS.

The files are sample Blue Wave packets that were included with two different versions of AmyBW, a Blue Wave reader for the Amiga. I have them in my collection of test packets for use with MultiMail, mainly to test LHA support. (Most offline reader packets are Zip files.) Initially, they extract OK, but when MultiMail tries to update the read marker file, LHa fails. I get slightly different errors with each packet, but I get them consistently across systems -- so far, I've only tried on a Raspberry Pi running 32-bit Raspbian (armv7l), and an M1 Mac running Big Sur (arm64). Here's what the output of LHa looks like:

demopkt.001

Initial extraction

DEMOPKT.DAT - Melted : oo
DEMOPKT.FTI - Melted : o
DEMOPKT.INF - Melted : o
DEMOPKT.MIX - Melted : o
DEMOPKT.XTI - Melted : o
NEWFILES.BW - Melted : o
READER1.NWS - Melted : o

Attempting to update the .xti

LHa: Error: Unknown level header (level 28)
DEMOPKT.xti - Frozen(40%) o

Second extraction

DEMOPKT.DAT - Melted : oo
LHa: Error: CRC error: "DEMOPKT.DAT"
LHa: Error: Unknown level header (level 80)

demopkt.002

Initial extraction

DEMOPKT.DAT - Melted : oooooooooooo
DEMOPKT.FTI - Melted : oo
DEMOPKT.INF - Melted : o
DEMOPKT.MIX - Melted : o
NEWFILES.XB - Melted : o
READER1.NWS - Melted : o

Attempting to update the .xti

LHa: Error: Unknown level header (level 35)
DEMOPKT.xti - Frozen(13%) o

Second extraction

DEMOPKT.DAT - Melted : oooooooooooo
LHa: Error: CRC error: "DEMOPKT.DAT"
LHa: Error: Unknown level header (level 58)

packets.zip

Test file: http://ace.cpcscene.net/_media/ace-morphos-1.14.lha

This file is created on MorphOS with the -e option to Amiga version of lha (to include empty directories). When extracting with this version of lha, I get empty files instead of empty directories for Discs, Grabs, Logs, ROMs, Share, Snapshots, and Tapes directories.

https://github.com/haikuports/haikuports/blob/master/app-arch/lha/patches/lha-1.14i.ac20191005.patchset

C89 fix: declaration after statement.
iconv: depending on how iconv is built, the symbol is named "iconv" or "libiconv". lha configure script detects libiconv in the library, but then checks again for the "iconv" symbol, and if not found, does not make use of iconv (but still links with it).

Thank you for this.
...would be nice to have to option to extract 1 (or more) files. Say I have a large file-list of lha archives, and inside each of these there is a *.readme file I wanne extract (and process / read).
I have 1000 lha files I open and process one file in the archive:

`
pi@raspberrypi:/src/src-code/test $ ls -l
total 8408
-rw-r--r-- 1 pi pi 1835853 Feb 5 22:31 A10TankKiller_v2.0_3Disk.lha
-rw-r--r-- 1 pi pi 2975982 Feb 5 22:33 AbandonedPlaces2_v2.0.lha
-rw-r--r-- 1 pi pi 3789038 Feb 5 22:32 AbandonedPlaces_v1.3_1000.lha
pi@raspberrypi:/src/src-code/test $ lha -l A10TankKiller_v2.0_3Disk.lha
PERMISSION UID GID SIZE RATIO STAMP NAME

[unknown] 900 48.7% Jul 6 2012 A10TankKiller3Disk.info
[unknown] 8098 61.7% Jul 6 2012 A10TankKiller3Disk/A10TankKiller3Disk.info
[unknown] 3656 73.4% Oct 6 2002 A10TankKiller3Disk/A10TankKiller3Disk.Slave
[unknown] 10380 60.8% Jul 6 2012 A10TankKiller3Disk/data/A10
[unknown] 82756 78.6% Mar 18 1992 A10TankKiller3Disk/data/A10.sfx
[unknown] 5562 28.1% Mar 18 1992 A10TankKiller3Disk/data/A10_20.icon
[unknown] 8008 48.3% Mar 18 1992 A10TankKiller3Disk/data/AmigaSnd.drv
[unknown] 1964 62.7% Mar 18 1992 A10TankKiller3Disk/data/c/avail
[unknown] 11284 54.8% Mar 18 1992 A10TankKiller3Disk/data/c/More
[unknown] 2568 61.1% Mar 18 1992 A10TankKiller3Disk/data/c/run
[unknown] 233380 85.2% Mar 18 1992 A10TankKiller3Disk/data/Cmp1.001
[unknown] 229 100.0% Mar 18 1992 A10TankKiller3Disk/data/Cmp1.RMF
[unknown] 223108 84.5% Mar 18 1992 A10TankKiller3Disk/data/Cmp2.001
[unknown] 229 100.0% Mar 18 1992 A10TankKiller3Disk/data/Cmp2.RMF
[unknown] 144919 86.8% Mar 18 1992 A10TankKiller3Disk/data/Cmp3.001
[unknown] 189 100.0% Mar 18 1992 A10TankKiller3Disk/data/Cmp3.RMF
[unknown] 16 100.0% Mar 18 1992 A10TankKiller3Disk/data/control.prf
[unknown] 232 51.7% Mar 18 1992 A10TankKiller3Disk/data/devs/system-configuration
[unknown] 900 37.8% Mar 18 1992 A10TankKiller3Disk/data/Drawer.icon
[unknown] 628 43.0% Mar 18 1992 A10TankKiller3Disk/data/Drawer20.icon
[unknown] 30548 94.8% Mar 18 1992 A10TankKiller3Disk/data/Install
[unknown] 92 80.4% Mar 18 1992 A10TankKiller3Disk/data/MName1.Dat
[unknown] 95 78.9% Mar 18 1992 A10TankKiller3Disk/data/MName2.Dat
[unknown] 92 77.2% Mar 18 1992 A10TankKiller3Disk/data/MName3.Dat
[unknown] 167496 52.1% Jul 6 2012 A10TankKiller3Disk/data/PS
[unknown] 1657 52.6% Mar 18 1992 A10TankKiller3Disk/data/ReadMe
[unknown] 235808 54.4% Jul 6 2012 A10TankKiller3Disk/data/Sim
[unknown] 5 100.0% Mar 18 1992 A10TankKiller3Disk/data/Vol1.Map
[unknown] 5 100.0% Mar 18 1992 A10TankKiller3Disk/data/Vol2.Map
[unknown] 5 100.0% Mar 18 1992 A10TankKiller3Disk/data/Vol3.Map
[unknown] 396448 80.8% Mar 18 1992 A10TankKiller3Disk/data/Volume.001
[unknown] 517925 86.3% Mar 18 1992 A10TankKiller3Disk/data/Volume.002
[unknown] 199451 95.5% Mar 18 1992 A10TankKiller3Disk/data/Volume.003
[unknown] 891 87.7% Mar 18 1992 A10TankKiller3Disk/data/Volume.RMF
[unknown] 47664 38.1% Oct 19 2001 A10TankKiller3Disk/Manual
[unknown] 1396 63.0% Jul 6 2012 A10TankKiller3Disk/Manual.info
[unknown] 2018 56.0% Oct 6 2002 A10TankKiller3Disk/ReadMe
[unknown] 1396 63.2% Jul 6 2012 A10TankKiller3Disk/ReadMe.info

Total 38 files 2341998 78.3% Feb 5 22:31
pi@raspberrypi:~/src/src-code/test $
`
I need to process each *.Slave files in each lha archive, like in this example the "A10TankKiller3Disk/A10TankKiller3Disk.Slave" file.

Hope you can implement it... Thanks!