Przesiadka na nowe środowisko

[bt2pac]

Cześć witam wszystkich po raz pierwszy!

Mam problem z przesiadkÄ… z BCB6 na BDS2006.
Chciałem skompilować sobie projekt który był wykonany w poprzednim środowisku BCB6, na BDS2006.
Jest z tym trochę problemów, krok po kroku radzę sobie z niektórymi, ale tym razem utknąłem i nie wiem co i jak dalej:
Projekt się kompiluje, jednak linker wyświetla taki error:

Kod: Zaznacz cały

[Linker Fatal Error] Fatal: Unable to open file 'SYSUTILS.OBJ'

Już kilka podobnych błędów wyświetlał jednak wtedy wystarczyło usunąć odpowiednie pragmy, w tym przypadku takiej nie ma.
Proszę nie tłumaczcie mi treści błędu z ang. na polski, bo to akurat świetnie rozumiem
Gdybym tylko miał taki plik to bym sobie poradził, ale takiego pliku nie ma ani w wersji starej ani w nowej

Nie wiem czy tyle szczegółów wystarczy czy może za mało.
W każdym razie będę wdzięczny za pomoc!!

Pozdrawiam!

[Cyfrowy Baron]

Wynika to z pewnej niezgodności bibliotek.

Spróbuj tak:

Zrób kopię całego projektu z BCB 6 - dla bezpieczeństwa.
Otwórz plik projektu BCB 6 (np. Project1.bpr) w Notatniku;

Odszukaj wartości:
<SPARELIBS value=
<PACKAGES value=

Może to wyglądać tak:

<SPARELIBS value="vcl.lib rtl.lib bcbie.lib vclZipForgeb6.lib vclx.lib Cyfrobar.lib PckWinXP.lib"/> <PACKAGES value="vcl.bpi rtl.bpi dbrtl.bpi adortl.bpi vcldb.bpi vclx.bpi bdertl.bpi vcldbx.bpi ibxpress.bpi dsnap.bpi cds.bpi bdecds.bpi qrpt.bpi teeui.bpi teedb.bpi tee.bpi dss.bpi teeqr.bpi visualclx.bpi visualdbclx.bpi dsnapcrba.bpi dsnapcon.bpi bcbsmp.bpi vclie.bpi xmlrtl.bpi inet.bpi inetdbbde.bpi inetdbxpress.bpi inetdb.bpi nmfast.bpi webdsnap.bpi bcbie.bpi websnap.bpi soaprtl.bpi dclocx.bpi dbexpress.bpi dbxcds.bpi indy.bpi bcb2kaxserver.bpi vclZipForgeb6.bpi"/>

Usuń wszystkie wpisy przypisane do0 tych wartości pozostawiając jednakże same wartości, powinno pozostać dokładnie tak:

<SPARELIBS value=""/> <PACKAGES value=""/>

Otwórz projekt w BDS 2006, dokonaj aktualizacji, której środowisko zażąda. Następnie wybierz polecenie MAKE, potem BUILD, a dopiero na końcu COMPILE. Powinno działać o ile w starym projekcie nie używałeś jakichś niestandardowych bibliotek, które nie występują w nowym środowisku.

[bt2pac]

W końcu się udało, nie było prosto ale poszło!
Dzięki Cyfrowy Baronie za podpowiedź posktutkowało.
Co prawda miałem jeszcze po drodze kilka problemów, ale powyższy problem przeskoczyłem dzięki Tobie!!
Jeszcze między czasie nasunęła mi się myśl że może też zadziałało by gdyby utworzyć nowy projekt i dodać do niego po prostu wszystkie pliki. Jednak niewątpliwie trwało by to dłużej bo plików mam ponad setkę i było by zabawy.

Dziękuję jeszcze raz i pozdrawiam!

[Cyfrowy Baron]

Jeszcze między czasie nasunęła mi się myśl że może też zadziałało by gdyby utworzyć nowy projekt i dodać do niego po prostu wszystkie pliki.

Już tego kiedyś próbowałem i stworzyło to zbyt wiele problemów, gdyż tworząc formularz i umieszczając na nim pliki środowisko automatycznie dodaje odpowiednie wpisy odnośnie użytych bibliotek do pliku projektu, gdy tylko dodasz pliki lub podmienisz, informacje o niestandardowych bibliotekach mogą nie zostać dodane, chociaż polecenia MAKE i BUILD powinny naprawić problem. Wydaje mi się, że ręczna edycja pliku jest prostrsza. Trzeba jeszcze projektowi wskazać gdzie znajdują się wszystkie niestandardowe biblioteki.

[bt2pac]

Jasne że:

tworząc formularz i umieszczając na nim pliki środowisko automatycznie dodaje odpowiednie wpisy odnośnie użytych bibliotek do pliku projektu

zgadzam się również że:

Wydaje mi się, że ręczna edycja pliku jest prostrsza.

ponieważ jest przede wszystkim szybsza, jednak:

gdy tylko dodasz pliki lub podmienisz, informacje o niestandardowych bibliotekach mogą nie zostać dodane, chociaż polecenia MAKE i BUILD powinny naprawić problem

tutaj nie rozumiem jednej rzeczy i jeżeli jesteś w stanie mi trochę to przybliżyć to byłbym wdzięczny.
Mianowicie jaka jest dokładnie w takim razie różnica pomiędzy ręczną edycją pliku a stworzeniem nowego projektu i dodaniem do niego wszystkich plików?

Przy ręcznej edycji pliku usuwamy pewne informacje z projektu (tak jak to pokazałeś) i oczekujemy od środowiska aby sobie projekt uaktualnił.
Kiedy projekt jest już uaktualniony to rozumiem że mamy sytuację taką samą jak w momencie po utworzeniu nowego projektu i dodaniu do niego wszystkich plików.
Ponieważ w obu przypadkach projekt jest aktualny w stosunku do wymagań środowiska oraz zawiera wszystkie pliki projektu.
Następny krok w obu przypadkach jest taki sam:

polecenia MAKE i BUILD powinny naprawić problem

Następnie wybierz polecenie MAKE, potem BUILD

Tak ja to rozumiem - oba sposoby są bardzo podobne i opierają się na tym samym pomyśle.
Natomiast Ty napisałeś:

Już tego kiedyś próbowałem i stworzyło to zbyt wiele problemów

więc rozumiem że jednak to nie to samo podejście. Więc gdzie jest różnica?

Być może ten drugi krok ma różną semantykę w tych przypadkach?
Jeżeli tak to jaką, jaka jest różnica?
No i oczywiście być może że podczas ręcznej edycji pliku projektu zostawiłem pewne informacje, które nie są standardowo dodawane do projektu np. o niestandardowych bibliotekach?

Będę wdzięczny za jeszcze jedną odpowiedź.

Pozdrawiam!

[Cyfrowy Baron]

Pytasz trochę chaotycznie. O różnicy między MAKE i BUILD było już na forum: viewtopic.php?f=2&t=524&p=3152&hilit=BUILD#p3169

na ogół wystarczy samo BUILD, ale np. w środowisku C++ Builder 2009 czasami pojawia się problem z plikami *.OBJ i wtedy samo BUILD nie naprawia tego problemu, ale gdy użyję najpierw MAKE a potem BUILD to błędy zostają naprawione, tak na marginesie to zamiast tego w tym konkretnym przypadku wystarczy uruchomić ponownie środowisko, więc jest to jakiś błąd środowiska, który być może naprawia jakiś patch, ale nie sprawdzałem jaki.

Gdy upuszczasz na formularz komponent to środowisko dodaje odpowiedni wpis do pliku nagłówkowego, (np. #include "langcb.h"), ale umieszcza umieszcza również wpisy w pliku projektu (np: langcb.obj). Gdy tyko dodasz do projektu pliki formularzem zawierającym taki niestandardowy komponent i wybierzesz tylko polecenie COMPILE to środowisko nie doda odpowiedniego wpisu do pliku projektu, czasami zdarza się że mimo to projekt zadziała, ale np. ponowne jego uruchomienie już wywołuje komunikat błędu.

Gdy usuwasz taki niestandardowy komponent z formularza to zauważ, że wpisy go dotyczące pozostają.

ten mój wpis:

Już tego kiedyś próbowałem i stworzyło to zbyt wiele problemów

dotyczy tej Twojej wypowiedzi:

Jeszcze między czasie nasunęła mi się myśl że może też zadziałało by gdyby utworzyć nowy projekt i dodać do niego po prostu wszystkie pliki.

Ręcznie usuwając z pliku projektu wpisy dotyczące bibliotek, tak naprawdę odświeżasz go, gdyż środowisko po wybraniu polecenia BUILD doda do tego pliku projektu potrzebne biblioteki, ale te które występują w nowym środowisku i połączy je właśnie z nimi i dlatego projekt działa, jeżlei w nowym środowsiku występują wszystkie niezbędne biblioteki występujące w starym,

[piotr.kwlk]

Witam czy mogę ponowić tam. Mianowicie mam podobny problem, jednak u mnie zmiana dotyczyła systemu operacyjnego posiadam bcb6 i windows7 64bit. Część projektów działa, a cześć nie dział po przeniesieniu ich ze starego kompa. Dałem sobie spokój , ale od wczoraj nawet nowe projekty mają podobny problem, ale gdy otworze poprzedni projekt działający, wszystko jest ok. Np mam komunikat Unable to open file "VCLDB.BPI". Stosowałem się do powyższych rad, przeszukałem internet i nie znalazłem odpowiedzi na moje pytanie. Dodam jeszcze, że ze względu że system zbytnio pilnie kontroluje Program Files zainstalowałem Borlanda bezpośrednio na C:

Po kolejnych próbach....
Próbuje i udało mi się czysty projekt uruchomić, gdy wyłączę w Projekt->Options->Packages opcje Build with runtime packages. Działają komponenty Standard i ADO, ale jak dodam komponent należący do Data Control w tym momencie znowu pojawia się [Linker Fatal Error] Fatal: Unable to open file 'VCLDB.LIB']. Włączenie opcji Build with runtime packages powoduje że komunikat jest ten sam nazwa pliku ta sama jedynie rozrzedzenie pliku to BPI. Gdy usunę ten komponent i wpisy z nim związane z wyłączoną opcją Build with runtime packages znowu działa. Próba włączenia opcji Build with runtime packages powoduje wyświetlenie komunikatu [Linker Fatal Error] Fatal: Unable to open file RTL.BPI'].

O co tu chodzi?

[Cyfrowy Baron]

Nie wiem jak to dokładnie jest z Windows 7, ale w wersji 64 bitowej aplikacje 32 bitowe instaluje się w katalogu Program Filesx86, nie wiem jednak czy poza zwykłym utrzymaniem rozgraniczenia między aplikacjami ma to jakieś znaczenie.

Środowisko BCB 6 nie zostało przystosowane do systemie 64-bitowym i posiada tylko sterowniki 32-bitowe. Mimo iż system Windows 7 x64 korzysta z mechanizmu WOW64, który pozwala emulować środowisko 32-bitowem, jednak nie wszystkie sterowniki mogą działać prawidłowo. Obawiam się, że ta wersja BCB nie będzie działać prawidłowo w systemie 64 bitowym. Potrzebujesz środowiska w wersji co najmniej Borland CodeGear Professional RAD Studio 2007.

Na tej stronie http://www.microsoft.com/windows/compatibility/windows-7/en-us/default.aspx można sprawdzić, czy program jest kompatybilny z Windows 7 wpisując w wyszukiwarkę hasło c++ builder. Wynika z tego, że dopiero wersja 2007 jest w pełni kompatybilna, ale nie Borland C++ Builder 2007 lecz Borland CodeGear Professional RAD Studio 2007.

[piotr.kwlk]

Pewnie masz rację, ale dotąd mi wszystko działało i jak uruchamiam poprzednie projekty wszystko jest ok. Mam wrażenie że coś to ma związek z danym projektem, jakaś konfiguracja jakiś zapis. Spróbuje zainstalować jeszcze raz Buildera. Może pomoże. Niestety na razie mogę zapomnieć a zakupie nowego kompilatora a nie chciałbym się z powrotem przesiadać na XP.

[Cyfrowy Baron]

Czy przypadkiem nie dzieje siÄ™ to w programie bazodanowym?

[piotr.kwlk]

90 % moim programów jest bazodanowych.