Ubuntu install location fixes

Clang Frontend
#1

Hi!

Here are fixes for clang on my system (Ubuntu 9.10 32 bit).

One remaining breakage:

/tmp/cc-UZRrfs.o:(.gnu.linkonce.r._ZZ18__gthread_active_pvE20__gthread_active_ptr+0x0): undefined reference to `__gthrw_pthread_cancel(unsigned long)'
collect2: ld returned 1 exit status
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [bla] Error 1

with this testcase:

#include <string>

int main()
{
  std::string bla;
  return 0;
}

Is this problem known?

g

0001-Move-Ubuntu-install-location.patch (2.02 KB)

0002-Fix-Ubuntu-32-bit-install-location.patch (1.13 KB)

#2

Hello,

Gonsolo ha scritto:

Hi!

Here are fixes for clang on my system (Ubuntu 9.10 32 bit).

I was sending a similar patch for debian sid which currently has stdc++ 4.4 that you can find attached. I see that at least a couple of ubuntu distribution have the very same version, do you think we consolidate the paths a bit at least for debian and ubuntu?

thanks,
riccardo

update-debian-sid-include-paths.diff (863 Bytes)

#3

I merged Ubuntu 9.10 and Debian sid. Patches attached.

g

0001-Move-Ubuntu-install-location.patch (2.02 KB)

0002-Fix-Ubuntu-32-bit-install-location.patch (1.13 KB)

0003-Update-Debian-Include-Paths.patch (1.23 KB)

0004-Merge-Ubuntu-and-Debian-include-paths.patch (1.79 KB)

#4

Gonsolo ha scritto:

#5

Since next stable debian will be released with 4.4 i think that the
comment should say squeeze. Then could you please diff the four patches
in one for easier review / test?

I donẗ know about Debian, I just did what you suggested. Can you provide a patch?

I use git for developing which automatically generates my patches. Isn't it easier to review with modular patches?

g

#6

Hello again :slight_smile:

Gonsolo ha scritto:

Since next stable debian will be released with 4.4 i think that the
comment should say squeeze. Then could you please diff the four patches
in one for easier review / test?

I donẗ know about Debian, I just did what you suggested. Can you provide a patch?

I just meant to rename "Sid" to "squeeze". Anyway not a big issue, we can remove the debian Sid entry and remove the ubuntu 8.10 entry which is wrong. Ubuntu 8.10 path is the same as 9.04 and debian squeeze / sid for now are the same as 9.10. So attached you can find a patch that consolidates the ubuntu paths.

Since this can lead to some confusion to non debian / ubuntu users we have to make some premises: first we have a link from /usr/include/c++/x.y to /usr/include/c++/x.y.z, then x.y.z may vary during debian testing and unstable development.

I use git for developing which automatically generates my patches. Isn't it easier to review with modular patches?

You move then delete the same hunk of code in two different patches, that's difficult to follow for me.

thanks,
riccardo

consolidate-ubuntu-paths.diff (2.1 KB)

#7

Hello again :slight_smile:

Gonsolo ha scritto:

Since next stable debian will be released with 4.4 i think that the
comment should say squeeze. Then could you please diff the four patches
in one for easier review / test?

I donẗ know about Debian, I just did what you suggested. Can you provide a patch?

I just meant to rename "Sid" to "squeeze". Anyway not a big issue, we can remove the debian Sid entry and remove the ubuntu 8.10 entry which is wrong. Ubuntu 8.10 path is the same as 9.04 and debian squeeze / sid for now are the same as 9.10. So attached you can find a patch that consolidates the ubuntu paths.

Since this can lead to some confusion to non debian / ubuntu users we have to make some premises: first we have a link from /usr/include/c++/x.y to /usr/include/c++/x.y.z, then x.y.z may vary during debian testing and unstable development.

I use git for developing which automatically generates my patches. Isn't it easier to review with modular patches?

You move then delete the same hunk of code in two different patches, that's difficult to follow for me.

Would it be possible to convince you guys to replace this with some code that uses the "last" directory in /usr/include/c++ with readdir? That way we could stop manually adding new versions.

-Chris

#8

Last time I looked at this code, it had a big FIXME saying it was the wrong approach. Since nobody else seems to be fixing this, I wonder if I should take a look at refactoring it. Maybe we should define a fixed location or two to look for a clang_header.conf file that will list standard include locations? Then distributions just need to provide this file, rather than having special cases for every single file. Maybe also add an option for overriding this file so that we can easily remove all system includes from the search path for cross-compiling?

If this approach sounds sensible then I'm happy to write the code. If someone else has a better idea, please let me know what it is...

David

-- Sent from my IBM 1620

#9

I think the best approach is to make this be a configure option at clang build time. Second to that, just making the code scan the /usr/include/c++ dir and pick the latest revision available would work.

-Chris

#10

Heh, in T2 I dynamically patch in the path of the current gcc:

  http://svn.exactcode.de/t2/trunk/package/develop/llvm/llvm.conf

I can implement readdir and possibly a configure option tomorrow.

  René

#11

I think the best approach is to make this be a configure option at
clang build time. Second to that, just making the code scan the
/usr/include/c++ dir and pick the latest revision available would
work.

I found a way to make it a cmake option which defaults to the latest revision available at compile time (which serves us lazy people who just want to do a "cd llvm/tools; ln -s ../../clang .; cd ..; mkdir build; cd build; cmake .."):

cat CMakeLists.txt:

...
FILE( GLOB cppdirs "/usr/include/c++/*" )
list( SORT cppdirs )
list( GET cppdirs -1 CXX_INCLUDE_DIRS)
MESSAGE( STATUS "CXX_INCLUDE_DIRS: ${CXX_INCLUDE_DIRS}" )
...

I am looking forward to implement this for clang. Would this be a preferred solution?

I also discovered C_INCLUDE_DIRS in the llvm CMakeLists.txt. Should I add my solution to llvm or clang?

g