FreeBSD 8.2 compile error (64 bits)

[GoogleCodeExporter]

Hi,

While trying to compile rar2fs 1.12.0 on freebsd 8.2 I'm getting this compile 
error:

gcc -g -rdynamic -fno-omit-frame-pointer -O2 -std=c99 -Wall  
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE 
-DHAS_GLIBC_CUSTOM_STREAMS_ -DRARDLL -DFUSE_USE_VERSION=27 -MD -I./unrar -I -c 
configdb.c
/usr/lib/crt1.o(.text+0x8a): In function `_start':
: undefined reference to `main'
gmake: *** [configdb.o] Error 1

Hope you can help me out with this since I'm not clever enough :)

Cheers,
Joris

Original issue reported on code.google.com by wiebel@gmail.com on 29 May 2011 at 12:15

[GoogleCodeExporter]

The problem is in the Makefile.
Make sure you assign a value to FUSE_SRC in config.mk.
I will correct this issue in next version.

Original comment by hans.bec...@gmail.com on 29 May 2011 at 7:42

• Changed state: Accepted

[GoogleCodeExporter]

The problem should be corrected in Makefile revision 188.
Check out latest version from trunk to obtain the fix.

Original comment by hans.bec...@gmail.com on 29 May 2011 at 1:12

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Hans,

Thanks for the prompt reply.
With the latest svn version I get the same error. 
If I edit config.mk I get a little further, the problem is though that freebsd 
ports have libunrar 3.something and not 4.x

I'm getting this error:

gcc -g -rdynamic -fno-omit-frame-pointer -O2 -std=c99 -Wall  
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_GNU_SOURCE 
-DHAS_GLIBC_CUSTOM_STREAMS_ -DRARDLL -DFUSE_USE_VERSION=27 -I/usr/local/include 
-MD -I./unrar -c rar2fs.c
rar2fs.c: In function 'extract_to':
rar2fs.c:205: warning: cast to pointer from integer of different size
rar2fs.c: In function 'popen_':
rar2fs.c:283: warning: implicit declaration of function 'fmemopen'
rar2fs.c:283: warning: assignment makes pointer from integer without a cast
rar2fs.c:298: warning: assignment makes pointer from integer without a cast
rar2fs.c:351: warning: cast to pointer from integer of different size
rar2fs.c: In function 'pclose_':
rar2fs.c:376: warning: implicit declaration of function 'killpg'
rar2fs.c:376: error: 'SIGKILL' undeclared (first use in this function)
rar2fs.c:376: error: (Each undeclared identifier is reported only once
rar2fs.c:376: error: for each function it appears in.)
rar2fs.c: In function 'getArcPassword':
rar2fs.c:1055: warning: cast to pointer from integer of different size
rar2fs.c: In function 'listrar':
rar2fs.c:1304: warning: assignment makes pointer from integer without a cast
rar2fs.c:1320: warning: assignment makes pointer from integer without a cast
rar2fs.c: In function 'sync_dir':
rar2fs.c:1533: warning: passing argument 3 of 'scandir' from incompatible 
pointer type
rar2fs.c: In function 'rar2_readdir':
rar2fs.c:1645: warning: passing argument 3 of 'scandir' from incompatible 
pointer type
rar2fs.c: In function 'rar2_init':
rar2fs.c:2121: warning: passing argument 1 of 'fclose' makes pointer from 
integer without a cast
gmake: *** [rar2fs.o] Error 1

Cheers,
Joris

Original comment by wiebel@gmail.com on 29 May 2011 at 3:55

[GoogleCodeExporter]

Joris, you need to set HAS_GLIBC_CUSTOM_STREAMS=n in config.mk.
That will fix the warning about fmemopen() etc.
Regarding the SIGKILL error, that is my mistake. I did some code restructuring 
and accidentally broke the build for FreeBSD :(
It should be fixed in rar2fs.c revision 189.

Original comment by hans.bec...@gmail.com on 29 May 2011 at 4:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hah! works! Thanks man :)
I will test later, now it's time for spareribs :P

Original comment by wiebel@gmail.com on 29 May 2011 at 4:23

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

You should probably consider building libunrar from source.
I have little hope that version 3 of the API will work, but you can always try 
;)
Note though that version 4 contains considerable performance improvements.

Original comment by hans.bec...@gmail.com on 29 May 2011 at 7:18