check_osmid throws error on 64 bit linux

[teddyimsuff]

in release 16.07, mt.pl line 1276ff there is only an elsif case for 32 bit linux. there needs to be another check for 64 bit linux since osmconvert32 won't work in 64 bit environment due to missing libraries.

e.g.:
/home/LATEST/tools/osmconvert/linux/osmconvert32: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory

[sroemer]

I do not have any expierience with Perl yet, but from what I found a possible solution could be to use POSIX uname (add use POSIX qw(uname); on top) and add an additional check of the unames machine name like shown below:

my @uname = uname();
if ( $uname[4] eq 'x86_64' || $uname[4] eq 'amd64' ) {
    $cmdpath = "$BASEPATH/tools/osmconvert/linux/osmconvert64";
}
else {
    $cmdpath = "$BASEPATH/tools/osmconvert/linux/osmconvert32";
}

Since the output of uname seems to be different on Linux and FreeBSD/OpenBSD the check for x86_64 and amd64 is needed (see here).

[teddyimsuff]

I can confirm this.
CentOS7 returns x86_64:
uname -a Linux mpbld 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Debian8 returns amd64:
uname -a Linux rmpbld2 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

[sroemer]

I think in your example the amd64 is part of the release string and not the machine name. The machine name on Debian is x86_64 as well (in front of GNU/Linux). In my case on Fedora23 it is x86_64 as well, but at least on BSD it will be amd64 and therefore the check is needed.

I already implemented what I wrote above and now tested it by doing a complete map build (I ramdomly chose Freizeitkarte_SWE). Everything worked fine for me now.

I pushed it to the develop branch of my Github fork of fzk-mde-garmin (see #4). Further testing on different Linux/BSD versions should be done.

[keenonkites]

Thanks guys, I'll implement this accordingly into the next release officially...

... just be aware: there are other tools that are only 32bit, which means that some sub commands of mt.pl will fail if you do not have the 32bits library installed.

[sroemer]

In general I think using 64bit Linux is very common these days and therefore the script and the tools should support it without any need for installing additional 32bit libraries.
But at least I was able to do a complete build of 2 different maps and I am quite sure that there are no 32bit libs on my Fedora installation currenty (but I need to verify this).

So I am wondering what tools and subcommands you are talking about. Could you please clarify that?

[keenonkites]

You're absolutely right, 64bit should be possible...
I know that jmc_cli is not 64bit, this is used for creating the gmap version of the map (Basecamp).

But I will check if there is a 64bit version available now.... I will also check if all other used tools are really 64bit.
I thought makensis wasn't, but there I was wrong, the point is that is just creates 32bit binary for windows... obviously I was puzzled by this.

BTW: I've implemented above in develop branch.... I moved this very first version of 64 bit detection to the starting of the script so I can reuse the result lateron not only for calling osmconvert.

Patrik

[sroemer]

OK, great. In case you need someone to do some testing on a 64bit Linux machine, just let me know. I have 2 machines, both running 64bit Fedora available.

[keenonkites]

I did some additional changes, moved the 64bit detection to separate subroutine and added the other uname variables too in that 'detection' subroutine... as well as all this stuff has been added to the output of the action 'fingerprint'.

Regarding testing: good to know as we have the 32bit libraries installed.... I'm wondering if building one map from a - z is running through is really running on 64bit only (without 32bit libraries):

Prepare Map Data (pmd) for LUX (small enough for quick tests):

perl mt.pl pmd LUX

Build Map Language (bml) for LUX:

perl mt.pl bml LUX

I assume building the gmap with jmc_cli will fail.... I didn't find any 64bit version.

[teddyimsuff]

java -Xmx1536M -jar /home/fzk-mde-garmin-develop/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar  --max-jobs=2 --license-file=license.txt --index --gmapsupp --product-id=1 --family-id=6442 --family-name="Freizeitkarte_LUX 16.08" --series-name="Freizeitkarte_LUX 16.08" --description="Freizeitkarte_LUX 16.08" --overview-mapnumber=64420000 --product-version=1608 6442*.img 6442.TYP
Time started: Wed Aug 17 13:43:39 CEST 2016
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Wed Aug 17 13:43:41 CEST 2016
Total time taken: 1922ms

Elapsed, System-RC, Action-RC: 3, 0, 0
TYP-File = 6442.TYP
TYP-File = contrast.TYP
TYP-File = freizeit.TYP
TYP-File = outdoor.TYP
TYP-File = outdoorc.TYP
TYP-File = outdoorl.TYP
TYP-File = small.TYP
Family-ID = 6442
IMG-File = 64420001.img
IMG-File = 64420002.img
IMG-File = 64420003.img
Ausgabe 16.08

Creating Freizeitkarte_LUX.nsi ...

zip -r Freizeitkarte_LUX_InstallFiles.zip *.img *.tdb *.mdx *.TYP
  adding: 64420001.img (deflated 15%)
  adding: 64420002.img (deflated 20%)
  adding: 64420003.img (deflated 21%)
  adding: Freizeitkarte_LUX.img (deflated 66%)
  adding: Freizeitkarte_LUX_mdr.img (deflated 91%)
  adding: Freizeitkarte_LUX.tdb (deflated 39%)
  adding: Freizeitkarte_LUX.mdx (deflated 34%)
  adding: 6442.TYP (deflated 64%)
  adding: contrast.TYP (deflated 64%)
  adding: freizeit.TYP (deflated 64%)
  adding: outdoorc.TYP (deflated 63%)
  adding: outdoorl.TYP (deflated 63%)
  adding: outdoor.TYP (deflated 63%)
  adding: small.TYP (deflated 64%)

Elapsed, System-RC, Action-RC: 1, 0, 0

makensis Freizeitkarte_LUX.nsi
Can't exec "makensis": No such file or directory at mt.pl line 876.

Warning: system(makensis Freizeitkarte_LUX.nsi) failed: -1
Failed to execute: No such file or directory

Elapsed, System-RC, Action-RC: 0, -1, 72057594037927935
ERROR:
  Compilation of Windowsinstaller for Freizeitkarte_LUX failed.

• Downloaded current dev-branch
• Build failed

A workaround is to create a gmap folder and install it via JaVaWa. That's what my workflow to create a EUROPE map.

[keenonkites]

thanks for the test.

Given failure is due to the fact that the NSIS (Null Soft Installer) isn't installed, unfortunately this is on the linux side not part of the development environment fzk-mde-garmin.

BTW: regarding jmc_cli: at the moment it doesn't look that good to get a 64bit version of that tool as it's not pure C or anything else we could just compile on linux.... it's inside a proprietary IDE called xojo

[teddyimsuff]

Question: wouldn't the "create-gmap-and-use-javawa-to-install-way" be a valid alternative for people who cannot or dont want to create maps under windows but in the end want to use the maps in windows environments?

[keenonkites]

there are always several ways to reach the aim.... it can also be assumed that most of the persons building their maps on their own are quite knowledged on one or the other platform.

[sroemer]

Please find attached the outputs of running both commands on my Machine (Fedora 23 - x86_64 - no 32bit libs)

What I saw is that jmc_cli failed, which was expected since there is no 64bit version of it.
Additionally I wondered about the first line saying "Redundant argument in printf at ./mt.pl line 4867". I think this is because the $directory variable is not used in the output string.

fzk_LUX_bml.txt
fzk_LUX_pmd.txt

[keenonkites]

many thanks for the tests and the output... I'll check/fix that as soon as I have some more time.

[teddyimsuff]

But is there another way (planed?) to build maps as a windows-installer under 64bit linux?

[keenonkites]

actually nothing is planned..... the tool, btw, is 64bit, it's just something that needs to be installed and is, like a few other 'basic' tools, not part of the distributed Development Environment.

[sroemer]

I did not have a look in that, but related to the missing NSIS (or other tools not being in the part of the development env.) I think it would be nice to have a message pointing the user in the right direction. Just explain that it needs to be installed separately or even give some links to what is needed if possible.

Besides this I wanted to have a look at the jmc_cli thing, but sadly it seems to be not an open source tool. I also found that page, explaining that 64bit support is in beta for Xojo (and started in a quite new version 2015 Release 3 which might not be what is used for jmc_cli).

[keenonkites]

Update on this:
mkgmap supports now building gmap archives directly, this means we can soon skip jmc_cli and are much nearer to 64bit for the complete Freizeitkarte Entwicklungsumgebung.