Compilation failed on FreeBSD 10. #31

hasse69 · 2015-03-13T10:13:22Z

What steps will reproduce the problem?

Run confuigure.
Run make.

What is the expected output? What do you see instead?

It should be compiled successfully. but, it failed.

What version of the product are you using? On what operating system?

FreeBSD 10.0-STABLE x86-64, rar2fs r462, unrar 5.0.14

# uname -a
FreeBSD localhost 10.0-STABLE FreeBSD 10.0-STABLE #2: Tue Mar  4 13:33:45 KST 2014     root@localhost:/usr/obj/usr/src/sys/STABLE-CUSTOM  amd64

Please provide any additional information below.

 - I'll attach config.log.
 - On FreeBSD, SIGXXX macro requires &lt;signal.h&gt;.
   Following error messages are result after fix that(add #include &lt;signal.h&gt;
   in rar2fs.c). Without this, it throws additional several error messages
   such as &quot;SIGINT not defined&quot;.

Compiler(clang 3.3 which is default compiler on FreeBSD 10) Messages:

    cc -DHAVE_CONFIG_H -I.  -I../unrar -I/usr/local/include -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=26  -DNDEBUG -Wall -g -O2 -fno-omit-frame-pointer -Wextra -Wno-unused-result -D_THREAD_SAFE -pthread -MT rar2fs.o -MD -MP -MF .deps/rar2fs.Tpo -c -o rar2fs.o rar2fs.c
    rar2fs.c:1733:54: error: no member named 'Method' in 'struct RARArchiveListEx'
                            S_ISDIR(mode) ? 2 : alist_p-&gt;Method - (FHD_STORING - 1);
                                                ~~~~~~~  ^
    rar2fs.c:4333:45: warning: unused parameter 'st' [-Wunused-parameter]
    static int64_t get_blkdev_size(struct stat *st)
                                                ^
    1 warning and 1 error generated.
    *** Error code 1

    Stop.
    make[1]: stopped in /mnt/shm/rar2fs-read-only
    *** Error code 1

    Stop.
    make: stopped in /mnt/shm/rar2fs-read-only

Original issue reported on code.google.com by jyhpsycho on 2014-03-06

The text was updated successfully, but these errors were encountered:

hasse69 · 2015-05-23T21:41:13Z

This is definitely the result of rushing things a bit. I do not have a working FreeBSD
environment to test on any more. I will try to sort these out, but I need some help
verifying that it works.

Original issue reported on code.google.com by hans.beckerus on 2014-03-06 10:32:52

hasse69 · 2015-05-23T21:41:17Z

Try r463.

Original issue reported on code.google.com by hans.beckerus on 2014-03-06 10:44:01

hasse69 · 2015-05-23T21:41:22Z

It doesn't work despite of above errors are resolved.

rar2fs.c:5000: undefined reference to 'libiconv_close'
rar2fs.c:333: undefined reference to 'libiconv'

It compiles sucessfully with -liconv. On Linux iconv functionality is part of glibc,
FreeBSD needs external libiconv library.



I wish you might add /usr/local/include, /usr/local/lib to default search path when
configuring under FreeBSD...

Original issue reported on code.google.com by jyhpsycho on 2014-03-06 11:33:55

hasse69 · 2015-05-23T21:41:27Z

The need for -liconv or not should be auto-detected through AM_ICONV. Need to look into
why it does not seem to work. Regarding the force add of /usr/local/lib and /usr/local/include.
No, I rather not. You should never need to enforce adding of default search paths for
libraries and headers like that. Mind I ask why you think you need it? If you have
specific needs for including these paths you should do it through the proper methods
as provided by autotools using config.site scripts or simply set CPPFLAGS="$CPPFLAGS
-I/usr/local/include"

Original issue reported on code.google.com by hans.beckerus on 2014-03-06 13:04:20

hasse69 · 2015-05-23T21:41:32Z

Btw, have you checked this link?
http://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html
Seems there is built-in support for iconv in FreeBSD 10?

Original issue reported on code.google.com by hans.beckerus on 2014-03-06 20:20:39

hasse69 · 2015-05-23T21:41:36Z

Could there be some conflict with the built-in iconv and a possible installed GNU version?
My guess is that (and judging from your config.log) that AM_ICONV detected the built-in
version which does not require an external library, but the header file (included from
rar2fs) actually is the one from the GNU iconv package, which wraps all calls to iconv()
and redirects them to libiconv instead?

Original issue reported on code.google.com by hans.beckerus on 2014-03-06 21:12:12

hasse69 · 2015-05-23T21:41:41Z

1. Oh, I have first time to see that link... Yes, that's my mistake. According to config.log,
FreeBSD 10 natively supports iconv()... But, Error message says libiconv(), not iconv()...
Is there any differences to these functions? If they are same function just have different
name, why it uses libiconv() instead of iconv()?

2. On FreeBSD, All library installed via ports(which is not included in base system)
is located on /usr/local/. fusefs-libs does, too - currently only kernel module is
included on base system. Because of that, now configure requires --with-fuse=/usr/local/include
and --with-fuse-lib=/usr/local/lib under "default setting" of FreeBSD 10. gcc 4.6 which
can install via ports searches these paths automatically, but clang 3.3 as default
base system compiler does not now.

Original issue reported on code.google.com by jyhpsycho on 2014-03-06 23:14:58

hasse69 · 2015-05-23T21:41:46Z

So true! This is actually a FreeBSD 10 artifact IMHO! I got the same problem when trying
to build the virtual box guest additions. That made me suspicious to what is really
going on and the answer (and solution) is actually rather simple. In FreeBSD 10 iconv
is actually delivered and built-in to the system. It does not really need an external
library any more. But the problem is that other packages (such as gettext) will still
install it as a dependency. So the end result is a system with both. This is also addressed
in the link I posted above, but only for FreeBSD ports. The reason why it fails for
rar2fs is because of a second artifact ;) Specifically that the fuse header files are
installed in /usr/local/include. Since you point --with-fuse to /usr/local/include
it also has the side effect that iconv.h will be picked up from there rather than /usr/include.
AM_ICONV on the other hand has no knowledge about the extra include path and thus picks
it up correctly. Now we have a conflict! Because the header file in /usr/local/include
requires the use of -liconv while the one in /usr/include does not! The fact that gcc
include /usr/local/include as part of the default search path (comapared to cc) is
interesting. What is the precedence of these paths? If gcc searches /usr/local/ *after*
/usr then it should automagically work if you switch from cc to gcc. But to use cc,
the easiest solution is to set --with-fuse to point to '/usr/local/include/fuse' and
not the '/usr/local/include'. Actually it is never a good idea to point out a complete
top folder like that and yet another reason to why it is always a bad idea to try to
add it to the default system search path using CPPFLAGS. A well behaving package should
always install itself under a specific sub-folder in eg. /usr/local/include. Fuse does
that.

Original issue reported on code.google.com by hans.beckerus on 2014-03-06 23:23:42

hasse69 · 2015-05-23T21:41:51Z

You can see gcc46's search paths typing following command:

# gcc46 -print-search-dirs

There's not explicitly displayed path /usr/local/include. It's strange behavior that
when using gcc46 there's no any problem finding fuse header and library without --with-fuse*
option. Even -liconv is correctly found!

But, there's another issue that gcc46 throws many errors seems to be related libstdc++...
such as "undefined reference to 'std::__1::basic_ostream<char, std::__1::char_traits<char>
>::put(char)'. It needs to more investigation...

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 00:11:08

hasse69 · 2015-05-23T21:41:55Z

gcc46 does not print path /usr/local/lib, too... I can't found that on output... :-(

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 00:13:12

hasse69 · 2015-05-23T21:42:00Z

I missed CXX='g++46'; with CC='gcc46' and CXX='g++46' it compiles successfully without
any modification. but, it still has portability problem that it requires gcc which
is deprecated by FreeBSD...

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 00:17:45

hasse69 · 2015-05-23T21:42:05Z

I do not understand? I was simply curious to why gcc may have added /usr/local/include
and /usr/local/lib to the default system search path. I never suggested it was a solution
to the iconv artifact on FreeBSD 10. My suggestion was to properly configure the package
before building by setting --with-fuse=/usr/local/include/fuse.
I built rar2fs successfully without warnings using clang by using this approach which
I consider the proper way of configuring the package before build. You should never
point package search path to /usr/local/include top directory unless really necessary.


So, what are the CXX and CC variables your are talking about? Are you setting this
in your environment before calling configure?
You say it still has portability problems? What portability problems?

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 06:38:01

hasse69 · 2015-05-23T21:42:09Z

Hmm... It seems need to more clarify the discussion;

I understands why you are not preferred to add default search path. That's just for
convenience, not important thing.

CC and CXX flags are needed to compile using gcc on FreeBSD. Setting both two variables,
rar2fs compiles without any error; despite of there's no --with-fuse* option. I don't
know why gcc46 does work without --with-fuse* option... it may be searches /usr/local/include
and /usr/local/lib automatically, I guess.

Portability problem I mentioned is..., Although using gcc on compile is work without
any error, That's not preferred way to build software under FreeBSD 10 and later becuase
That's default compiler is clang, not gcc. If clang works without any source-level
modification, there's no problem - just my mistake. I'll test your suggestions when
reinstalling FreeBSD is done.

Original issue reported on code.google.com by jyhpsycho on 2014-03-07 11:00:04

hasse69 · 2015-05-23T21:42:14Z

Ok, then we are on the same level again ;)
Yes, I had no issues what so ever to build rar2fs using clang (after fixing the reported
errors). I did however have some issues compiling libunrar.so using clang though, but
that is out of scope of this discussion (eg. I had to use 'gmake' and it spitted out
a lot of warnings). Please report back when you know more.

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 11:43:27

hasse69 · 2015-05-23T21:42:19Z

One problem I have noticed is that starting rar2fs in the foreground (-f) and then trying
to abort it using CTRL-C does not work very well? It works once (but very slow) but
the second time it seems to hang forever!? Something you can verify? It seems it gets
stuck on the fuse_unmount() call. Probably something related to the fuse kernel module.
Can not recall that I have ever seen this on eg. FreeBSD 8.x.

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 22:09:09

hasse69 · 2015-05-23T21:42:24Z

There is definitely something wrong on FreeBSD 10 with the combination of fuse unmount!
If I try to replace fuse_unmount() with unmount() it still hangs. If I remove the call
to fuse_unmount()/unmount() completely it works, but then we are instead left with
a stale mount point. I seem to have found a workaround though. That is to remove the
call to fuse_unmount() and call unmount() later after the file system tear down is
complete. This is for sure a bug in FreeBSD! I can not recall having seen this on 8.2
so it might actually be something that was introduced in some of the later versions
:(

Original issue reported on code.google.com by hans.beckerus on 2014-03-07 22:57:19

hasse69 · 2015-05-23T21:42:28Z

You're right. I reinstalled FreeBSD, compiled all needed library from scratch on ports,
used --with-fuse=/usr/local/include/fuse and --with-fuse-lib=/usr/local/lib and it
works.

Actually, /usr/local/include/fuse.h contains just #include "fuse/fuse.h" for backward
compatibility by default, then it should work with --with-fuse=/usr/local/include.
I checked that and it works, too.

I reproduced some of your new problems. When mounting without -f option and try to
unmount, it finally unmounted sucessfully but it hangs several seconds. With -f option
and press Ctrl-C, that's behavior just same as unmount mentioned before. I can't reproduce
hang forever... I use manually compiled version of FreeBSD 10 now, not 10.0-RELEASE.
But it does not important thing I think...
I'll describe source version I currently use.

svn.freebsd.org/base/stable/10, r262871
svn.freebsd.org/ports/head, r347334

fuse-freebsd: version 0.4.4, FUSE ABI 7.8
fusefs-libs-2.9.3_2

Original issue reported on code.google.com by jyhpsycho on 2014-03-08 02:09:35

hasse69 · 2015-05-23T21:42:33Z

Hi. The fuse.h in /usr/local/include is a troll. I think most people will agree with
that. Yes, it is there for backwards compatibility but it also creates a lot of problems
like in this case. If it worked for you to use --with-fuse=/usr/local/include then
it is probably because you do not have a iconv.h there too. Maybe your system now is
using only the built-in support?

The unmount problem is annoying. I run FreeBSD in a VBox instance so the complete hang
might be caused by some other reason. But it is good that you were able to verify that
unmount is very slow. It is not much I can do about it though. I have a workaround
but I do not really like it that much for me to commit it yet. An issue report should
probably be filed towards FreeBSD or the fuse-kmod port that is uses. 

I think this case can be closed.

Original issue reported on code.google.com by hans.beckerus on 2014-03-08 09:10:15

hasse69 · 2015-05-23T21:42:38Z

Hmm... strange. /usr/local/include/iconv.h exist there... But, because of it works with
--with-fuse=/usr/local/include/fuse, I'll use that.

I agree that this case can be closed.

Original issue reported on code.google.com by jyhpsycho on 2014-03-08 09:31:13

hasse69 · 2015-05-23T21:42:42Z

Agreed then.
Case closed.

Original issue reported on code.google.com by hans.beckerus on 2014-03-08 09:49:34

hasse69 · 2015-05-24T18:25:09Z

Btw, here is the reason why it works using --with-fuse=/usr/local/include for gcc but
not for clang

[extract from config.log using gcc]
checking how to link with libiconv... -liconv

When using gcc the AM_ICONV macro identifies the need for linking towards the external
GNU iconv package. But when doing the same using clang it probably picks up the "built-in"
header file instead and the conflict is a fact.
Must be something in how gcc and clang handles default include paths. One thing seems
sure though, they handle them differently. I would stick with setting --with-fuse=/usr/local/include/fuse
in this case. Then you avoid the problem irrespectively of what compiler you choose
to use.

Original issue reported on code.google.com by hans.beckerus on 2014-03-08 10:19:47

hasse69 · 2015-05-24T18:25:14Z

From the gcc onlinedocs, http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

--
2.3 Search Path

GCC looks in several different places for headers. On a normal Unix system, if you
do not instruct it otherwise, it will look for headers requested with #include <file>
in:

     /usr/local/include
     libdir/gcc/target/version/include
     /usr/target/include
     /usr/include
--

So there it is. gcc will always find iconv.h in /usr/local/include first and force
the need to link towards the external GNU iconv package. The only way to workaround
this is to mess with the gcc flag -nostdinc, but I would stay away from it ;)
Stick with clang and --with-fuse=/usr/local/include/fuse.

Original issue reported on code.google.com by hans.beckerus on 2014-03-08 10:36:30

* Turned off support for block special device mounts other than for Linux platforms. It does not make much sense trying to support it any where else due to possible read alignment restrictions. * Built and tested against UnRAR source 5.10 beta 1 (5.1.1) * [rar2fs hasse69#34] Fixed a problem with old style archives split into more than 101 files. * Now returning "No such file or directory" instead of "Input/output error" when trying to read information for a file outside an archive or which does not exist at all (libunrar5 only). * Fixed an issue when retrieving file information (#info) that could have resulted in an infinite loop. * Fixed an issue with resolving symbolic links for legacy archives in combination with libunrar5. * Corrected some issues that caused compilation failures for UnRAR source 4.1.x. * Corrected a problem seen on e.g. FreeBSD for which closedir() was called with a NULL pointer resulting in a crash. * [rar2fs hasse69#31] Corrected some compilation errors on FreeBSD (and also other platforms that sets HAVE_SETXATTR). * Mounting block special files on Linux can now benefit from fmemopen() when supported. * Enabled syslog support * [rar2fs hasse69#22] Now may fall back to the old workaround from 1.19.2 that should be working also for (some!?) uClibc versions of fmemopen(). * Corrected some additional problems with the solution for issue hasse69#22. * Added support for presenting high-resolution time stamp in RAR5 archives (thanks to jyhpsycho for the initial patch). Legacy archives still require a new version of UnRAR source before it can be enabled. * [rar2fs hasse69#28] Fixed problem with mounting a block special file that resulted in a crash due to incorrect use of mmap() and fmemopen(). * Added a missing check for errors from fmemopen() * [rar2fs hasse69#29] Fixed a minor calculation error in the file time stamp 'seconds' part as provided by libunrar (MS-DOS time format). * Removed 'INSTALL' from SVN trunk

hasse69 self-assigned this Mar 13, 2015

hasse69 added Defect Priority-Medium labels Mar 13, 2015

hasse69 closed this as completed Mar 13, 2015

hasse69 mentioned this issue Mar 13, 2015

Cannot list any contents in archive on FreeBSD 10. #33

Closed

hasse69 removed their assignment Mar 13, 2015

Nischi85 mentioned this issue Oct 9, 2022

stacked file system gets unmounted #177

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compilation failed on FreeBSD 10. #31

Compilation failed on FreeBSD 10. #31

hasse69 commented Mar 13, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 24, 2015

hasse69 commented May 24, 2015

Compilation failed on FreeBSD 10. #31

Compilation failed on FreeBSD 10. #31

Comments

hasse69 commented Mar 13, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 23, 2015

hasse69 commented May 24, 2015

hasse69 commented May 24, 2015