[Gambas-user] rev5866 build error

[Tobias Boege]

On Wed, 02 Oct 2013, paulwheeler wrote:
> I do not know what I did to upset you Tobias and Beno?t, but I am just
> reporting what I see.
> 
> Both of you have asked whether I Followed instructions or not. I believe
> I answered that in the first email: "..... I follow the "How To Deal
> With Subversion" instructions exactly."
> 
> Yes, Beno?t, I did "issue a './reconf-all' as stated in the "How To Deal
> With Subversion" instructions?"
> 
> Tobias, "What could help is sending the configure script ...."  The
> script is the one included in the 5866 trunk. I just followed
> instructions and did: "./configure -C"

Impossible, as a configure script does not exist in trunk. It is generated
by reconf(-all). You should also keep in mind that there are multiple
configure scripts involved.

> 
> Before reporting this problem with libintl and libiconv, I did my
> research and found where they are in the Ubuntu package (see information
> in my last email).
> 
> >> According to the Ubuntu packages page (see address below), the only
> >> libintl.so file is:
> >> /usr/lib/preloadable_libintl.so  which is in this package: gettext
> >>
> >> gettext and gettext-base are both installed.
> >>
> 
> This says that in raring, the libintl is part of gettext! I am just
> quoting from the Ubuntu package page.
> 
> The name is different in Ubuntu Raring, so is that the real problem here?
> 

Quoting is not enough - you have to understand what you say! We are looking
for libintl.so not for preloadable_libintl.so. And no, this is not a faulty
string in the Gambas configuration process.

Turns out (from a web search as I don't use this distro), Ubuntu ships glibc
with its libintl inside and preloadable_libintl is an alternate libintl from
the gettext package, as you already found out.

> I did confirm that  "/usr/lib/preloadable_libintl.so" is installed on my
> system.
> 
> You said: "On all setups that I've seen (which are not much, though),
> the glibc includes intl."
> 
> According to the Ubuntu packages page, gettext is a "build-depends"
> package for eglibc which generates libc6, so that may be why you think
> it is in libc.
> 

On Arch Linux you would do something like

$ pacman -Qo $(echo "#include <libintl.h>" | cpp -H 2>&1 >/dev/null | grep -o "[^ ]*libintl.h")
/usr/include/libintl.h is owned by glibc 2.18-4

To find out that glibc comes with the libintl stuff Gambas uses. I'm pretty
sure you can replace "pacman -Qo" with the command appropriate for Ubuntu
and get a similar result.

> 
> Tobias, your comment about YOUR configure and my not noticing the
> warning was not appreciated.

What a pity. It is fact, however, that configure is generated and chances
are that the file on my computer is different from yours and so can be line
numbers and everything. I couldn't find a "cd" in line 17062 mentioned in
your report (where your configure fails to enter some directory) - I would
not have asked for the file otherwise! It's just that configures on
different systems are _different_.

> I used the configure from the trunk, and
> yes, I did notice that line, which is why I included so much information
> about the libiconv package in my email.
> 
> libiconv has been installed using synaptic, but the names are different:
> /usr/lib/libiconv_hook.so.1  and  /usr/lib/libiconv_hook.so.1.0.0
> 

The names are different because the things are different. According to
Ubuntu's package page, libiconv-hook1 is some "extension for
libapache-mod-encoding". I'm pretty sure this is nothing Gambas relies on.

Again, replacing libintl.h with iconv.h in the above command, it yields on
Arch Linux:

$ pacman -Qo $(echo "#include <iconv.h>" | cpp -H 2>&1 >/dev/null | grep -o "[^ ]*iconv.h")
/usr/include/iconv.h is owned by glibc 2.18-4

I expect similar results on Ubuntu when "pacman -Qo" is replaced by the
right dpkg charm.

> 
> So, the fact remains that the names are different in Ubuntu raring.
> 

This is a non-issue. I don't want to appear grumpy again but I don't
understand why we talk this much about this stuff. These are plain
*warnings* which we all (at least most of us) see in every configure run
under main/.

These warnings are obviously not even remotely connected to the actual
problem you're facing. intl and iconv are (parts of) shared libraries and
these are only needed when linking, i.e. after compiling. Your configure
process stops even before the Makefiles are generated so this is a point far
away from linking.

The real problem is that for some reason your configure wants to access a
/home/Paul/Gambas directory which does not exist on your system. The big
question is where the configure script got this path from!

> I have attached the output files from reconf-all and configure
> 

The output from configure finally solves the puzzle, I think. You checked
the SVN repository out to a directory named "/home/paul/Gambas trunk 5866"
as can be seen from this line, e.g.:

--8<--[ Gambas5866Configure_output.txt ]------------------------------------
[...]
=== configuring in main (/home/paul/Gambas trunk 5866/main)
[...]
--8<------------------------------------------------------------------------

Some line in some configure script probably doesn't wrap this path in quotes
correctly (or doesn't use backslashes to mask the spaces) so that
/home/paul/Gambas is taken as a path.

Don't put spaces into path names. It only makes life harder, IMHO.

You certainly understand that I smiled when I noticed this because if you
really *exactly* followed the HowTo, your directory would have been named
"trunk" and we wouldn't have had to rack our brains on this.

Regards,
Tobi

PS: Concerning the line

--8<--[ reconf-all_output ]-------------------------------------------------
root at ...3202...:/home/paul/Gambas trunk 5866# ./reconf-all >> reconf-all2.txt
--8<------------------------------------------------------------------------

It is not considered good practice to compile (or prepare to compile) as
root.

PPS: I'm CC'ing the list again. It got lost with your last mail apparently.

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk