Re: Small patch for the QNX platform

[Ralf Wildenhues]

Hello Mike,

* Mike Gorchak wrote on Fri, Jan 23, 2009 at 12:37:34PM CET:
> >> This patch adds qnx as platform which supports library version
> >> information.
>
> RW> As far as I can see, this patch changes the versioning scheme used on
> RW> QNX.  This means, that potentially all libraries created with libtool
> RW> after this change are incompatible with all of those created before.
>
> No, it is not changes versioning scheme, it adds support for the 
> versioning under QNX. I did not found any incompatibilities with already 
> compiled and installed libraries.

Ah, ok.  Thanks for this explanation.

> RW> I see you supplied the last QNX-related change to Libtool, too, in
> RW> 2004. Can you provide information about why this change is needed now?
> RW> Did QNX change their versioning, or why is this necessary now?
>
> The main problem why I added support for QNX is libdrm, which I porting 
> to QNX right now, libdrm uses "-version-number 2:4:0", but libtool fails 
> on the following check:

>       # Check that each of the things are valid numbers.
>       case $current in
>       
> 0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9])
>  ;;
>       *)
>         func_error "CURRENT \`$current' must be a nonnegative integer"
>         func_fatal_error "\`$vinfo' is not valid version information"
>         ;;
>       esac

> because $current is empty at this point. I will mark an error and my
> comments to the script below with >>>> sign.

>       case $vinfo_number in
[...]
>         case $version_type in
>         darwin|linux|osf|windows|none)
[...]
>
>>>>> since QNX is not listed platform and $version_type contains 
>>>>> "qnx", the variables $current, $age and $revision are not set and 
>>>>> empty at
>>>>> this point. So this cause a problem with $current check for the
>>>>> non-negative number and non-digit characters.
>         esac
>         ;;
>       no)
>         current="$1"
>         revision="$2"
>         age="$3"
>         ;;
>       esac


Ah ha.  Our testsuite needs to expose this issue.  This is a good point
to add some test exposure to versioning.  Patch coming up in another
mail.  I would like you to try out that patch: after applying it, run
  make check-local TESTSUITEFLAGS='-v -d -x -k versioning'

and ensure that, without your change, the test fails, and with your
change, the test passes.  If that is not the case, please show the
respective test output.

> RW> Also, we would be extremely interested in seeing testsuite (make -k
> RW> check) output of Libtool on this system.
>
> For the first bunch of tests (103) there are 3 was failed, but they
> are failed because of using gcc command line instead of QNX's QCC
> wrapper around GCC. QNX uses Dinkumware C++/STL library instead of
> using GNU stdc++, but g++ searching for the libstdc++ instead of
> dinkumware libcpp library. This problem could be easily solved by
> setting CC=qcc and CXX=QCC. But it was too late to specify qcc instead
> of gcc, because I'm using not fast computer for QNX development and
> almost of half tests has been completed when found this error, running
> all these tests took a lot of time. But if you need, I could re-run
> all test suite with QCC wrapper for C++ without any problem :) Log
> attached. Looks like there are few problems, which are not related to
> C++. I will check them.

Yes.  Thanks for your testing.  Please post the tests/testsuite.log file
for the testing that you have already done.  Then please also
reconfigure (or, if you are using separate build trees, set up another
build tree) with qcc/QCC:
  path/to/libtool/configure -C CC=qcc CXX=QCC
  make
  make -k check

and send verbose results for that, too, including log.  For getting
verbose output for the old and the new testsuite, please see the README
file.

Thank you,
Ralf